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. Current code: /etc/rc.d/init.d/xinetd [snip] start(){ echo -n "Starting xinetd: " daemon xinetd -reuse -pidfile /var/run/xinetd.pid RETVAL=$? echo touch /var/lock/subsys/xinetd return $RETVAL } [snip] 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]? Panic
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 a problem. Panic
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-2.1.8.9pre12-1 and above