http://wiki3.caucho.com/index.php?title=Linux_service&feed=atom&action=historyLinux service - Revision history2024-03-29T14:36:21ZRevision history for this page on the wikiMediaWiki 1.18.0http://wiki3.caucho.com/index.php?title=Linux_service&diff=2109&oldid=prevSam: Linux boot moved to Linux service2006-02-27T20:41:42Z<p>Linux boot moved to Linux service</p>
<table class='diff diff-contentalign-left'>
<tr valign='top'>
<td colspan='1' style="background-color: white; color:black;">← Older revision</td>
<td colspan='1' style="background-color: white; color:black;">Revision as of 20:41, 27 February 2006</td>
</tr></table>Samhttp://wiki3.caucho.com/index.php?title=Linux_service&diff=2108&oldid=prevSam: migration2006-02-27T20:40:03Z<p>migration</p>
<p><b>New page</b></p><div>''Thanks to Guy McArthur and Carlos Hanson for the examples and much of the explanation for this tutorial.''<br />
<br />
== Modifying httpd.sh ==<br />
<br />
The easiest way to start Resin when Linux boots is to modify your<br />
httpd.sh and create symbolic link in /etc/rc.d/rc3.d and /etc/rc.d/rc5.d.<br />
Because the boot process does not set environment variables, you'll need<br />
to set them in the httpd.sh.<br />
<br />
# Copy httpd.sh to "resin-a.sh" in resin/bin and change permissions.<br />
# Configure JAVA_HOME, RESIN_HOME, PATH, and "-pid" in resin-a.sh.<br />
# Check that "resin-a.sh start" and "resin-a.sh stop" work from the command line when running as root.<br />
# "ln -s /usr/local/resin/bin/resin-a.sh /etc/rc.d/rc3.d/S86resin-a"<br />
# "ln -s /usr/local/resin/bin/resin-a.sh /etc/rc.d/rc5.d/S86resin-a"<br />
# "ln -s /usr/local/resin/bin/resin-a.sh /etc/rc.d/rc2.d/K14resin-a"<br />
# Reboot to test.<br />
<br />
A sample resin-a.sh might look like:<br />
<br />
<!-- pre --><br />
#! /bin/sh<br />
#<br />
# ...<br />
#<br />
JAVA_HOME=/usr/java<br />
export JAVA_HOME<br />
<br />
RESIN_HOME=/usr/local/resin<br />
export RESIN_HOME<br />
<br />
PATH=/bin:/usr/bin:/usr/local/bin<br />
export PATH<br />
<br />
args="-Xms75M -Xmx100M start -pid $RESIN_HOME/resin-a.pid"<br />
class=com.caucho.server.http.HttpServer<br />
name=httpd<br />
<br />
perl=/usr/local/bin/perl<br />
<br />
exec $perl $RESIN_HOME/bin/wrapper.pl -chdir -name "$name" \<br />
-class "$class" $args $*<br />
<!-- /pre --><br />
<br />
An advantage of this method is that you can use the same script<br />
to start and start the server interactively.<br />
<br />
== Linux booting background ==<br />
<br />
At startup, Linux runs the /etc/rc.d/rc script at the current runlevel<br />
(normally 3 or 5). All the Sxx scripts in /etc/rc.d/rc3.d/S*<br />
are started in order.<br />
<br />
<!-- pre --><br />
for i in /etc/rc$runlevel.d/S*; do<br />
$i start<br />
done<br />
<!-- /pre --><br />
<br />
So S86resin-a will be called as "S86resin-a start" as the root user.<br />
Since the script can't assume any environment variables, it needs to set<br />
them itself.<br />
<br />
Since Resin is an application, as opposed to a system service, it<br />
should be started late in the boot process. S86 is a decent choice. The<br />
specific order only matters if your startup depends on another service.<br />
For example, if you have a load-on-startup servlet that depends on a<br />
database, the database should be S85 or lower.<br />
<br />
Some configurations boot up in runlevel 3 and others boot<br />
in runlevel 5. The actual boot order will then be {1,2,3} or {1,2,5}.<br />
A machine booting with runlevel 3 will have /etc/inittab with the following<br />
line:<br />
<br />
<!-- pre --><br />
id:3:initdefault<br />
<!-- /pre --><br />
<br />
On server shutdown, Linux calls the scripts in /etc/rc.d/rc2.d/K*<br />
in order.<br />
<br />
<!-- pre --><br />
for i in /etc/rc$runlevel.d/K*; do<br />
$i stop<br />
done<br />
<!-- /pre --><br />
<br />
In this case, Resin is an application, as opposed to a system service, it<br />
should be killed early in the shutdown process.<br />
<br />
== Alternatives ==<br />
<br />
An alternative to modifying the httpd.sh is to create another script<br />
that passes arguments to the original httpd.sh.<br />
<br />
<!-- pre --><br />
#!/bin/sh <br />
<br />
# script name: resin <br />
# <br />
# start/stop script for Resin <br />
<br />
RESIN_HOME=/usr/resin <br />
JAVA_HOME=/usr/java/jdk1.3 <br />
PATH="$PATH:/usr/java/jdk1.3/bin:/usr/X11R6/bin" <br />
export PATH JAVA_HOME RESIN_HOME <br />
<br />
${RESIN_HOME}/bin/httpd.sh -Xms75M -Xmx100M -java_home ${JAVA_HOME} "$*" <br />
<!-- /pre --><br />
<br />
Guy McArthur writes<br />
<br />
I find it a bit easier to edit wrapper.pl rather than creating a<br />
script that passes in environment variables. But that's just because<br />
I'll be starting/stopping resin manually using httpd.sh to try<br />
something out, so having that single point of control is good.<br />
<br />
Carlos Hanson writes:<br />
<br />
I originally started by editing wrapper.pl, but having a script<br />
that passes the necessary arguments to httpd.sh allows me to<br />
reinstall or upgrade Resin more easily. All I have to worry about<br />
is configuration files. This is important when dealing with developers new<br />
to Unix and maintaining a large number of production and development<br />
servers. We keep the script and the conf files in source control.</div>Sam