Bug 18819 - /etc/rc.d/init.d/xinetd does not properly check to make sure the service was started
Summary: /etc/rc.d/init.d/xinetd does not properly check to make sure the service was ...
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: xinetd   
(Show other bugs)
Version: 7.0
Hardware: i386 Linux
Target Milestone: ---
Assignee: Trond Eivind Glomsrxd
QA Contact: David Lawrence
Depends On:
TreeView+ depends on / blocked
Reported: 2000-10-10 15:01 UTC by Panic
Modified: 2007-03-27 03:36 UTC (History)
2 users (show)

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

Attachments (Terms of Use)

Description Panic 2000-10-10 15:01:59 UTC
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:



	echo -n "Starting xinetd: "
	daemon xinetd -reuse -pidfile /var/run/xinetd.pid
	touch /var/lock/subsys/xinetd
	return $RETVAL


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]?


Comment 1 Panic 2000-10-10 15:03:26 UTC
I just re-read this entry -- urrggg, too early in the morning for clarity. :)

Comment 2 Trond Eivind Glomsrxd 2000-10-10 15:05:56 UTC
Is this really a problem?

Comment 3 Panic 2000-10-10 17:15:03 UTC
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.


Comment 4 Trond Eivind Glomsrxd 2000-10-17 14:48:51 UTC
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 16:21:53 UTC
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 16:24:04 UTC
The fix should turn up in  xinetd- and above

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