Bug 48901
| Summary: | bogus message from xinetd | ||
|---|---|---|---|
| Product: | [Retired] Red Hat Linux | Reporter: | Richard Kettlewell <rkettlewell> |
| Component: | xinetd | Assignee: | Trond Eivind Glomsrxd <teg> |
| Status: | CLOSED NOTABUG | QA Contact: | Ben Levenson <benl> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 7.0 | ||
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | i386 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2001-07-16 15:44:32 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
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 xinetd bug. 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. 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 misconfigured. 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 problem. 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. |
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.17-14 i686; en-US; 0.8) Gecko/20010215 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.