Bug 404881

This problem still occurs in fc9-alpha1 as of this date.

Hi Ray, please update to the current version of the package --
system-config-services-0.99.6-1.fc9 -- as this has been revamped almost
completely compared to what's been in the Alpha.

I suspect that the init script of the APC agent might not have chkconfig or LSB
compatible headers which system-config-services needs to recognize it as a
service it can handle. Please attach the script to this bug.

#!/bin/sh
case "$1" in
start)
        runlevel | grep 1 > /dev/null
        if [ $? = 0 ]
        then
            echo Can not start in runlevel 1
            exit 1
        fi
        ps `cat /etc/pbeagent.pid 2>/dev/null | awk "{ print "'$1'" }"` | grep
Dpicard.main.thread > /dev/null
        if [ $? = 0 -a -e /etc/pbeagent.pid ]
        then
                echo Process Already Started. Cannot start twice.
        else
                cd /opt/APC/PowerChuteBusinessEdition/Agent 
                export
LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/opt/APC/PowerChuteBusinessEdition/Agent/lib/linux
                /bin/java/jre/1.4.2_11/bin/java -Dpicard.main.thread=blocking
-classpath
./lib/AdvSnmp.jar:./lib/application.jar:./lib/jsdk.jar:./lib/comm.jar:./lib/mail.jar:./lib/RXTXComm.jar:./lib/util.jar:./lib/m11.jar:./lib/ds.jar:./lib/pcbe_ds.jar:./lib/sss.jar:./lib/activation.jar:./Resources/Japanese.jar:./comp/AliCommunication.jar:./comp/CommandFileRunner.jar:./comp/DataLogger.jar:./comp/DiscoveryListener.jar:./comp/EventLogger.jar:./comp/EventTracker.jar:./comp/Host.jar:./comp/http.jar:./comp/picard.jar:./comp/PowerSource.jar:./comp/QueryServer.jar:./comp/Security.jar:./comp/ShutdownBehavior.jar:./comp/Shutdowner.jar:./comp/SimpleBroadcaster.jar:./comp/SMTPMailer.jar:./comp/UPSManagerAutoUpdate.jar:./comp/shutdownerlets/OSShutdownerlet.jar
com.apcc.m11.application.PicardApplication @critical.cfg 2>/dev/null 1>/dev/null &
                echo $! >/etc/pbeagent.pid
                touch /var/lock/subsys/PBEAgent 1>/dev/null 2>/dev/null
                exit $?
        fi
        ;;
stop)
        PID=`cat /etc/pbeagent.pid 2>/dev/null | awk "{ print "'$1'" }"`
        kill $PID 1>/dev/null 2>/dev/null
        rm -f /etc/pbeagent.pid 1>/dev/null 2>/dev/null
        rm -f /var/lock/subsys/PBEAgent 1>/dev/null 2>/dev/null
        exit $?
        ;;
status)
        ps `cat /etc/pbeagent.pid 2>/dev/null | awk "{ print "'$1'" }"` | grep
Dpicard.main.thread > /dev/null
        if [ $? = 0 -a -e /etc/pbeagent.pid ]
        then
                echo Running
        else
              echo Stopped
        fi
        ;;
*)
        echo "Usage $0 {start|stop|status}"
        exit 1
        ;;
esac

As you can see this doesn't really have any headers.   Where would one find out
about the headers needed?

In order to be handled by system-config-services (or chkconfig), an init script
must have the LSB headers[1,2,3], should have the chkconfig headers[2,3] (as
they have additional info like pidfiles) and must return proper exit codes[2,3,4].

[1]:
http://www.linux-foundation.org/spec//booksets/LSB-Core-generic/LSB-Core-generic.html#INITSCRCOMCONV
[2]: http://fedoraproject.org/wiki/PackagingDrafts/SysVInitScript
[3]: http://fedoraproject.org/wiki/FCNewInit/Initscripts
[4]:
http://www.linux-foundation.org/spec//booksets/LSB-Core-generic/LSB-Core-generic.html#INISCRPTACT

I'll close this BZ for now, as this is not a bug in s-c-services. Feel free to
still ask questions though if you have any.

OK.  It would be nice if the help system had this information in it.

I also will see about updating this script.   Once I get that working I will
post it here if you don't mind in addition to contacting the vendor.

Created attachment 297258 [details]
PBEAgent script that works

Thanks for the script. Some comments/questions though:

- The pidfile should be /var/run/pbeagent.pid, not /etc/pbeagent.pid -- /etc
might be readonly.

- To let system-config-users benefit from the pidfile, a "# pidfile: ..."
comment needs to be added, e.g.:
# pidfile: /var/run/pbeagent.pid

- The chkconfig-style (non-LSB) options (like "pidfile" ;-) are only evaluated
if a "# chkconfig: <runlevels> <startprio> <stopprio>" comment exists. In this
case it would be:
# chkconfig: 2345 50 50

- Does this daemon do the right thing out of the box or does it need to be
configured before you can use it? In that case, it should not be started by
default, but only if the user enables it via chkconfig or system-config-users.
To do this, the following changes are needed:
# chkconfig: - 50 50
[...]
# Default-Start:
# Default-Stop: 0 1 2 3 4 5 6

Makes sense?

I debated the default line.

Here is the deal and my logic on that.   "Right out of the box" it does nothing,
but does it well. It also is not normally even an issue as the file normally is
not even there. 

That is if you run the script, the deamon loads finds that it can't do anything
because of a lack of a control file, and exists with a nice message in the
messages file.   So having it default to start is not a problem.  

There is a gzip file of the applicable files and a list of where to copy them,
but there is also an rpm.   If you use the gzip then it would be possible to
have the init file exist without a configuration.  But this will not be the case
with an rpm install which is what people normally will do.  The rpm install
doesn't actually install this file in the etc init.d and rcx.d directories.  
Seems dumb, but I didn't write it ;-)  The configuration script that you are
supposed to run right after you install it with the rpm creates the control
file, and then copies the right entries to the init.d and rcx.d directories.  
It also copies them as Sxx entries.   So it seemed that the best match was the
default this to on.

Your more expert thoughts?

Sounds good -- it seems to install the init script only if the service is
configured. The worst that could happen is (as you described), that it gets
started, doesn't find its configuration and stops and (possibly) gets flagged as
"dead" in system-config-services.