if you maintain a package that ships a SysV initscript, this message is
I've meant to write this mail in a long time. The overhaul of
system-config-services for Fedora 9 revealed that some of the current
SysV initscripts could be improved. System-config-services relies on the
scripts to be standard-conformant, which means that they must have a
certain structure (chkconfig, LSB headers) and support certain
actions (start, stop, restart, status) which give appropriate exit
codes. Then there are scripts that technically conform to the
standard, but could make system-config-services behave better with some
I'll give some real life examples below, which are not to single out
anybody, only as reference.
The issues I have found so far are:
- Some scripts always give a zero exit code on "status" (atd).
System-config-services interprets a zero exit code as "service is
running" and doesn't let the user start a service that e.g. is actually
stopped. The error here may be that the return code of the status
function isn't properly passed to exit.
- Some scripts give erroneous exit codes on status, e.g. openvpn gives
"1" if it isn't running which is interpreted as "dead".
- Some scripts return exit codes reserved for non-status actions on
"status", e.g. rpcgssd returns 6 on "status" here, probably because it
isn't configured on my system. This will let such services be shown with
an "unknown" status, or worse, a bogus one.
- Some scripts list a pidfile in the chkconfig/non-LSB header(*), but
the daemon doesn't write it (anacron). In this case,
system-config-services will wait on that file to appear, which never
will happen so the service will always be listed as "stopped".
(*): The existence of a pidfile helps system-config-services
tremendously because it can then just monitor the actual processes and
instantly respond to status changes. The absence of a pidfile means that
system-config-services can only react to intentional status changes, but
won't detect a service dieing for whatever reason. If your service
writes a pidfile, but your script doesn't reflect it, please add the
chkconfig header "pidfile: /path/to/pidfile" and/or the LSB header
"X-Fedora-Pidfile: /path/to/pidfile" (the latter one will be supported
in future versions of the tool). If your service doesn't write a
pidfile, well, it should ;-).
- Some scripts aren't starting long-running daemons, but execute
nonrecurring actions. These often also just return a zero exit code on
"status", but this doesn't reflect if they in fact have been run or not
(udev-post). System-config-services can't tell one kind from the other,
so while this situation isn't covered by the standard, it would be very
helpful if these scripts tried to emulate a "normal" service as close as
possible. I.e. if they just touched /var/lock/subsys/<name> on "start",
removed it on "stop", ran "stop" then "start" on "restart" and let
status return 0 or 3 depending on if that files exists. This would let
the user see some reaction in the interface on their actions.
- Some scripts use backslashes for continuation in the LSB description
(xinetd). In the service description of the LSB header, you can specify
that lines are to be continued by having the next line start with
"#<tab>" or "# " (hash + two or more spaces). Using backslashes here
will let them appear in the service description which doesn't look too
I've already filed some bugs on that and will do so when I come across
problematic initscripts, but I'd really appreciate if you could quickly
check your scripts against these things because I won't find everything
by myself ;-).
Nils Philippsen "Those who would give up Essential Liberty to purchase
Red Hat a little Temporary Safety, deserve neither Liberty
email@example.com nor Safety." -- Benjamin Franklin, 1759
PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011
fedora-devel-list mailing list
08-27-2008, 04:06 PM
system-config-services and you
On Friday 22 August 2008 09:10:40 Nils Philippsen wrote:
> I've already filed some bugs on that and will do so when I come across
> problematic initscripts, but I'd really appreciate if you could quickly
> check your scripts against these things because I won't find everything
> by myself ;-).
I take this opportunity to ask for a maintainer/co-maintainers to ifplugd. I
don't use anymore as I am happy with NetworkManager even for desktop machines.
The package has low maintenance and has no open bugs the only reason for not
keeping it is the fact that I don't use anymore.
> Thanks and feedback welcome,
fedora-devel-list mailing list