Bug 18819 - /etc/rc.d/init.d/xinetd does not properly check to make sure the service was started
/etc/rc.d/init.d/xinetd does not properly check to make sure the service was ...
Status: CLOSED RAWHIDE
Product: Red Hat Linux
Classification: Retired
Component: xinetd (Show other bugs)
7.0
i386 Linux
low Severity medium
: ---
: ---
Assigned To: Trond Eivind Glomsrxd
David Lawrence
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2000-10-10 11:01 EDT by Panic
Modified: 2007-03-26 23:36 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2000-10-17 17:52:34 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Panic 2000-10-10 11:01:59 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.

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
Comment 1 Panic 2000-10-10 11:03:26 EDT
I just re-read this entry -- urrggg, too early in the morning for clarity. :)
Comment 2 Trond Eivind Glomsrxd 2000-10-10 11:05:56 EDT
Is this really a problem?
Comment 3 Panic 2000-10-10 13:15:03 EDT
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
Comment 4 Trond Eivind Glomsrxd 2000-10-17 10:48:51 EDT
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.
Comment 5 Trond Eivind Glomsrxd 2000-10-19 12:21:53 EDT
The author added a "-stayalive" option so we can do this. I still thinks this
isn't an issue, though.
Comment 6 Trond Eivind Glomsrxd 2000-10-19 12:24:04 EDT
The fix should turn up in  xinetd-2.1.8.9pre12-1 and above

Note You need to log in before you can comment on or make changes to this bug.