Red Hat Bugzilla – Bug 18819
/etc/rc.d/init.d/xinetd does not properly check to make sure the service was started
Last modified: 2007-03-26 23:36:25 EDT
If xinetd is installed but no services are enabled, the startup script
erroneously indicates that xinetd was started (placing a pid file in
/var/run/), and the shutdown script attempts to shutdown the xinetd process
and fails (because the pid file exists -- for example, when the machine is
shut down). In other words, the startup script indicates [OK], but the
process immediately dies because no services are enabled, leaving an
orphaned PID file.
echo -n "Starting xinetd: "
daemon xinetd -reuse -pidfile /var/run/xinetd.pid
This returns [OK] even though the process immediately dies after starting
up, since there are no services enabled. I don't know how to fix this --
maybe grepping for the "disable = no" line anywhere in the config file or
config directory, or possibly checking ps for the process actually being
running before returning [OK]?
I just re-read this entry -- urrggg, too early in the morning for clarity. :)
Is this really a problem?
It is generating tickets -- 2 for me so far, "why does xinetd fail when I shut
down?" and "I installed my tftp server, but I can't connect. xinetd startup
says it is [OK]...". Since most xinetd services are installed disabled by
default, this situation could easily occur for a number of different services,
especially POP/IMAP mail servers. A stock Server install doesn't fail because
of the default services -- rsh, rlogin, finger, etc. And isn't having a PID
file for a process that isn't running generally a Bad Thing(tm)?
It's not exactly high priority, granted, but it is confusing, especially to
newer users who don't think to check ps or /var/log/messages to see if the
daemon is actually running or passed an error on startup. So yes, I think it is
OK... Very low, if any, priority: This really isn't a problem.
If something reports failed when shutting down, it certainly quits when killing
processes. No bad side effects either.
The author added a "-stayalive" option so we can do this. I still thinks this
isn't an issue, though.
The fix should turn up in xinetd-22.214.171.124pre12-1 and above