< Zurück | Inhalt | Weiter >

20.5.2 RedHat/Fedora chkconfig

RedHat and its stepchild, Fedora, use a program called chkconfig to automate the setup and integration of init scripts.

The chkconfig program has four basic functions. Two involve adding and removing services from management. That’s our main interest here, but we’ll get to that in a moment. The other two involve querying and setting the run- levels in which services run. That is the more common use, so we’ll look at those first.

[root@host238 root]# chkconfig --list ntpd

ntpd 0:off 1:off 2:off 3:on 4:off 5:on 6:off


chkconfig --list without specifying a service name will list all the services managed by chkconfig, including those that are provided by xinetd, which we will not cover here.


As you can see, ntpd runs at runlevels 3 and 5, and does not run at any others. The --list argument lets you query the runlevels.

[root@host238 root]# chkconfig --levels 2345 ntpd on [root@host238 root]# chkconfig --list ntpd

ntpd 0:off 1:off 2:on 3:on 4:on 5:on 6:off

The --levels argument lets you specify a list of runlevels that will apply to the named service. The last argument may be on or off to specify which setting to apply to those runlevels. The current value (on or off) for a specified


13. Just a quick reminder that not all Linux distributions name their directories or scripts in precisely the same way, but they all use something similar. By examining the /etc/inittab file and the contents of the /etc directory, you should be able to figure out the details of any given distribution. Over time, more and more distributions have come to exactly match the naming scheme described here. RedHat, Fedora, and Debian, for example, all follow this naming scheme.

runlevel is overwritten by whatever you specify. There is more to this; see the manpage for chkconfig for details.

Now, before we put JBoss under management, we need to make a script for it. Or rather, we need to modify the one provided by JBoss. In the bin subdirectory of JBoss, you will find a script called jboss_init_redhat.sh. You will notice that it has the “chkconfig mojo” in it—that is, the “chkconfig:” comment line. We mentioned this in passing when we looked at the atd init script, but we didn’t tell you what those three numbers after the colon actually mean. The first is the list of runlevels in which you want the program to run. The second is the start priority, which is the number that will follow the S in the rcX.d runlevel symlink directory. The third number is the stop priority, which is the number that will follow the K in the rcX.d runlevel symlink directory.

These start and stop priority numbers can be very important indeed. Some services (like NFS) depend upon others (like portmap). Your JBoss server might depend on a service like mysqld or postgresql. Don’t toy with these orders lightly. You can seriously mess up your services if you don’t know what you are doing. Still, you will probably have to tweak things to get them completely right. Just be cautious and think about every change.

Example 20.4 is the script as it comes with JBoss 3.2.3.

There are three things we have to change here. The first are the runlevels in the “chkconfig:” line (we’ll show you the changed lines with a couple of lines of context):


# chkconfig: 345 80 20

# description: JBoss EJB Container


Next, we may need to change the paths to JBoss and to the Java runtime. In our case, if you installed into /usr/local and created the symbolic link as we suggested, you don’t need to change the JBOSS_HOME, but you have to change the JAVAPTH variable:14


14. We are assuming you have set up your Java SDK as described in Chapter 6. If your java*

commands are located somewhere else, change this path to point at them.


Example 20.4 Out-of-the-box JBoss init script for RedHat



# JBoss Control Script


# chkconfig: 3 80 20

# description: JBoss EJB Container


# To use this script,

# run it as root - it will switch to the specified user.

# It loses all console output - use the log.


# Here is a little (and extremely primitive)

# startup/shutdown script for RedHat systems. It assumes

# that JBoss lives in /usr/local/jboss, it's run by user

# 'jboss' and JDK binaries are in /usr/local/jdk/bin. All

# this can be changed in the script itself.

# Bojan


# Either amend this script for your requirements

# or just ensure that the following variables are set correctly

# before calling the script.

# [ #420297 ] JBoss startup/shutdown for RedHat

# define where jboss is - this is the directory

# containing directories log, bin, conf, etc. JBOSS_HOME=${JBOSS_HOME:-"/usr/local/jboss"}

# make sure Java is on your path JAVAPTH=${JAVAPTH:-"/usr/local/jdk/bin"}

# define the classpath for the shutdown class


# define the script to use to start jboss JBOSSSH=${JBOSSSH:-"$JBOSS_HOME/bin/run.sh -c all"}

if [ -n "$JBOSS_CONSOLE" -a ! -d "$JBOSS_CONSOLE" ]; then

# ensure the file exists touch $JBOSS_CONSOLE


if [ -n "$JBOSS_CONSOLE" -a ! -f "$JBOSS_CONSOLE" ]; then

echo "WARNING: location for saving console log invalid: $JBOSS_CONSOLE" echo "WARNING: ignoring it and using /dev/null" JBOSS_CONSOLE="/dev/null"


# define what will be done with the console log JBOSS_CONSOLE=${JBOSS_CONSOLE:-"/dev/null"}

# define the user under which JBoss will run,

# or use RUNASIS to run as the current user JBOSSUS=${JBOSSUS:-"jboss"}


CMD_STOP="java -classpath $JBOSSCP org.jboss.Shutdown --shutdown"

if [ "$JBOSSUS" = "RUNASIS" ]; then SUBIT=""


SUBIT="su - $JBOSSUS -c "


if [ -z "`echo $PATH | grep $JAVAPTH`" ]; then export PATH=$PATH:$JAVAPTH


if [ ! -d "$JBOSS_HOME" ]; then

echo JBOSS_HOME does not exist as a valid directory : $JBOSS_HOME exit 1



case "$1" in start)

cd $JBOSS_HOME/bin

if [ -z "$SUBIT" ]; then







if [ -z "$SUBIT" ]; then







$0 stop

$0 start



*) esac

echo "usage: $0 (start|stop|restart|help)"

# define where JBoss is - this is the directory

# containing directories log, bin, conf, etc. JBOSS_HOME=${JBOSS_HOME:-"/usr/local/jboss"}

# make sure Java is on your path JAVAPTH=${JAVAPTH:-"/usr/java/jdk/bin"}

Finally, we don’t need to run the “all” configuration, we only need the default configuration at the moment, so we change the argument to the run.sh invocation:


# define the script to use to start JBoss JBOSSSH=${JBOSSSH:-"$JBOSS_HOME/bin/run.sh -c default"}

JBoss Configurations

When you unpacked JBoss, it contained three predefined server configu- rations located in jboss/server. The three configurations are named all (which runs every single service JBoss supports, including RMI/IIOP and clustering features), default (which runs only the set needed to run servlets, JSP, and EJBs), and minimal (which runs just JNDI, the logger, and a URL deployment service; no Web container, no JMS, no EJBs).

In effect, the selected configuration is the server. You can, of course, customize any configuration, and you may create additional configurations.

Now, this script allows you to run JBoss as any user. It defaults to user jboss if none is specified. You have to decide what to do here. Without speci- fying a user, it will run as root. That is a major security risk. On an out-of-the- box RedHat or Fedora system, there is no user called jboss. We will have to create one. There are a lot of security concerns to creating a special “nonlogin” user. The most important involve changing the user entries in /etc/passwd


Example 20.5 Using chkconfig to include JBoss start script

[root@cvs root]# cd /usr/local/jboss/bin

[root@cvs bin]# cp jboss_init_redhat.sh /etc/init.d/jboss [root@cvs bin]# chkconfig --add jboss

[root@cvs bin]# chkconfig --list jboss

jboss 0:off 1:off 2:off 3:on 4:on 5:on 6:off [root@cvs bin]# /etc/init.d/jboss start

CMD_START = cd /usr/local/jboss/bin; /usr/local/jboss/bin/run.sh -c default


and /etc/shadow after you create the user. Unfortunately, the JBoss program needs to run a shell script, so you cannot set the shell to /sbin/nologin as is usual. Set the password for the user in /etc/shadow to x, which is completely invalid and will forbid login to the account by password.

Finally, you will need to add the user jboss to any groups you created for JBoss management (such as local in our case). Truth be told, it would be a good idea to use the jboss user to install JBoss. It will avoid having to deal with some file ownership and permission issues. If you do not do this, the simplest way to get this init script working (you will get permission errors) is to run

chmod -R g+w /usr/local/jboss

That will make the script work with the jboss user, provided jboss be- longs to the group owner of the JBoss installation.

The final step is to copy your modified script to its final destination and run chkconfig to install it in all the runlevels (Example 20.5).

You now have JBoss running. You can start and stop it with the script, and it will come up and shut down automatically depending on the runlevel you switch to. Beauty, eh?