Bug 48901 - bogus message from xinetd
bogus message from xinetd
Product: Red Hat Linux
Classification: Retired
Component: xinetd (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Trond Eivind Glomsrxd
Ben Levenson
Depends On:
  Show dependency treegraph
Reported: 2001-07-12 09:33 EDT by Richard Kettlewell
Modified: 2007-04-18 12:34 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2001-07-16 11:44:32 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Richard Kettlewell 2001-07-12 09:33:26 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.17-14 i686; en-US; 0.8)

Description of problem:
I have the following in xinetd.d:

[root@persephone /root]# cat /etc/xinetd.d/nntp
# default: on
service nntp
	socket_type		= stream
	wait			= no
	user			= richard
	log_on_success		+= USERID
	log_on_failure 		+= USERID
	server			= /home/richard/tools/p4nntp

However at boot time I get the following in /var/log/messages:

Jul 12 14:09:46 persephone xinetd[591]: Service nntp missing attribute server

As you can see the "server" attribute is patently not missing.

Anyway the nntp service is not started.  Reloading xinetd starts the
service up properly, but I'd like it to start it at boot time.

What I believe is going on is that xinetd is noticing that the p4nntp
binary is unavailable at boot time (presumably due to the order in which
filesystems are mounted) and deciding to disable the service.  If this is
what is really going on then (1) the error message should be amended to
make this clearer and (2) xinetd shouldn't refuse to start services due to
transient unavailability.
Comment 1 Trond Eivind Glomsrxd 2001-07-12 19:37:28 EDT
So you're claiming that it doesn't work at startup, but it will work if you just
do a "service xinetd reload" afterwards? 

If that's the case, I'd check to see if having your nntpserver on /usr/local (or
another filesystem available at boot) helps.
Comment 2 Richard Kettlewell 2001-07-13 11:38:59 EDT
"/etc/init.d/xinetd reload", but yes.

I should have the results of the suggested test sometime on Monday.
Comment 3 Richard Kettlewell 2001-07-16 05:21:19 EDT
Yes, having the server on a fs available at boot time does cause xinetd to start it.

Comment 4 Trond Eivind Glomsrxd 2001-07-16 10:05:27 EDT
OK, closing as notabug - xinetd checking that the server is available is not an
xinetd bug.
Comment 5 Richard Kettlewell 2001-07-16 10:07:44 EDT
Err, it is a bug.  The server is transiently unavailable when xinetd starts up,
but that doesn't imply it's unavailable in the future.  Testing only at startup
is wrong-headed.
Comment 6 Trond Eivind Glomsrxd 2001-07-16 10:11:41 EDT
This is almost the definition of "it's a feature, not a bug". It even tells you
exactly which service doesn't have a server - checking later, when accessed,
would cause the service to be dropped then. Better to know that your service is
Comment 7 Richard Kettlewell 2001-07-16 10:43:08 EDT
The service is not misconfigured.  xinetd has just guessed wrongly that it is. 
Note that I'm not complaining about the existence of the log message (though it
nees to be re-worded) but about the disabling of the service.

The possible cases are as follows:

1) Service transiently unavailable at boot time, current xinetd behavour: you
get a boot-time log message, and the service doesn't work.

2) Service always unavailable, current xinetd behaviour: you get a boot-time log
message, and the service doesn't work.

3) Service transiently unavailable at boot time, xinetd disabling behaviour
suppressed: you get a boot-time log message, but the service just works.

4) Service always unavailable, xinetd disabling behaviour supppressed: you get a
boot-time log message, and the service doesn't work.

As you can see removing the current disabling behaviour only improves the situation.
Comment 8 Trond Eivind Glomsrxd 2001-07-16 10:49:23 EDT
I disagree with "it's a bug". This is a admin problem.
Comment 9 Richard Kettlewell 2001-07-16 11:44:27 EDT
The misleading log message is not an admin problem.

The absence of any mention of this behaviour in the man page is not an admin

Those two points aside, I've already pointed out above that the feature adds no
useful behaviour, and that it does have annoying behaviour.  If you disagree
with my reasoning you could at least say what part of it you find incorrect.
Comment 10 Trond Eivind Glomsrxd 2001-07-23 22:58:09 EDT
Checking that arguments are valid at startup is a perfectly valid strategy. 

If you disagree, I can consider a patch if you make one (I'm not promising to
apply it) but I don't have any issues with the current behaviour and don't
consider it bogus. Not only does it check (which is good), it even tells you
what is wrong.

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