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
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: 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
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.
"/etc/init.d/xinetd reload", but yes.
I should have the results of the suggested test sometime on Monday.
Yes, having the server on a fs available at boot time does cause xinetd to start it.
OK, closing as notabug - xinetd checking that the server is available is not an
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
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
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.
I disagree with "it's a bug". This is a admin problem.
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.
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.