Bug 1075152
| Summary: | modify the xinetd man page to make it more clear on what happens to services on xinetd reload | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | Dave Sullivan <dsulliva> | ||||||
| Component: | man-pages-overrides | Assignee: | Jan Chaloupka <jchaloup> | ||||||
| Status: | CLOSED ERRATA | QA Contact: | Iveta Wiedermann <isenfeld> | ||||||
| Severity: | medium | Docs Contact: | |||||||
| Priority: | medium | ||||||||
| Version: | 6.6 | CC: | dsulliva, isenfeld, jchaloup, moagrawa, ovasik, pschiffe | ||||||
| Target Milestone: | rc | Keywords: | EasyFix, ManPageChange, Patch | ||||||
| Target Release: | --- | ||||||||
| Hardware: | Unspecified | ||||||||
| OS: | Unspecified | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | man-pages-overrides-6.6.2-1.el6 | Doc Type: | Bug Fix | ||||||
| Doc Text: |
Cause: xinetd man page was not clear about what happens to services during xinetd reload
Consequence: unexpected behaviour
Fix: add information about what happens to services during xinetd reload
Result: updated documentation
|
Story Points: | --- | ||||||
| Clone Of: | |||||||||
| : | 1146259 (view as bug list) | Environment: | |||||||
| Last Closed: | 2014-10-14 07:26:59 UTC | Type: | Bug | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Embargoed: | |||||||||
| Bug Depends On: | |||||||||
| Bug Blocks: | 994246, 1119317, 1146259 | ||||||||
| Attachments: |
|
||||||||
Created attachment 902167 [details]
warning of xinitd reload termination handling
Hi, Dave,
is this patch ok for you? Added:
BEWARE of xinetd reload termination handling. For services with type = INTERNAL, SIGTERM signal will be sent. For services without type = INTERNAL, SIGKILL signall will be sent. Take this into an account when deadling with proper handling of the SIGTERM and SIGKILL. It is important to be aware of this as your xinetd service could be killed on a xinetd reload.
at the end of the DESCRIPTION section.
The patch looks reasonable. But, please, s/deadling/dealing/. Created attachment 908063 [details]
warning of xinitd reload termination handling
Done
Thanks for the patch! Looks good to me. Thx. Hello, Dave, should we clone this bug for rhel7.1? I went ahead and cloned this for rhel7. Even though people should probably be moving their services into the systemd domain...e.g telnet. I'm assuming some may still have a reason to rely on xinetd. Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2014-1382.html |
Description of problem: The man page does not make the following clear. As per xinetd code xinetd send SIGTERM signal to child only for those service whose are internal (means the service is provided by xinetd) in all other case it will send SIGKILL signal to any non internal service. void terminate_servers( struct service *sp ) { int sig = SC_IS_INTERNAL( SVC_CONF( sp ) ) ? SIGTERM : SIGKILL ; deliver_signal( sp, sig ) ; } This can cause an out of service issue unknowing with an xinetd reload. The request here is have the man page document this scenario. ====== BEWARE: xinetd reload termination handling Services type = INTERNAL on a reload will be sent a SIGTERM, so your service can do the necessary on proper handling of the SIGTERM Services without type = INTERNAL on a reload will be sent a SIGKILL It is important to be aware of this as your xinetd service could be killed on a xinetd reload. ===== Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info: When sending a SIGHUP to Xinetd (e.g. by running "service xinetd reload"), the child processes are killed with a SIGKILL. This is logged: 2014-01-29T12:14:50.873461-06:00 ll-chiptest01 xinetd[2021]: Starting reconfiguration 2014-01-29T12:14:50.878848-06:00 ll-chiptest01 xinetd[2021]: Swapping defaults 2014-01-29T12:14:50.878901-06:00 ll-chiptest01 xinetd[2021]: readjusting service chiptest 2014-01-29T12:14:50.878945-06:00 ll-chiptest01 xinetd[2021]: Sending signal 9 to chiptest server 26573 2014-01-29T12:14:50.879817-06:00 ll-chiptest01 xinetd[2021]: Sending signal 9 to chiptest server 26573 2014-01-29T12:14:50.879871-06:00 ll-chiptest01 xinetd[2021]: EXIT: chiptest status=0 pid=26573 duration=10(sec)When sending a SIGHUP to Xinetd (e.g. by running "service xinetd reload"), the child processes are killed with a SIGKILL. This is logged: 2014-01-29T12:14:50.873461-06:00 ll-chiptest01 xinetd[2021]: Starting reconfiguration 2014-01-29T12:14:50.878848-06:00 ll-chiptest01 xinetd[2021]: Swapping defaults 2014-01-29T12:14:50.878901-06:00 ll-chiptest01 xinetd[2021]: readjusting service chiptest 2014-01-29T12:14:50.878945-06:00 ll-chiptest01 xinetd[2021]: Sending signal 9 to chiptest server 26573 2014-01-29T12:14:50.879817-06:00 ll-chiptest01 xinetd[2021]: Sending signal 9 to chiptest server 26573 2014-01-29T12:14:50.879871-06:00 ll-chiptest01 xinetd[2021]: EXIT: chiptest status=0 pid=26573 duration=10(sec) 2014-01-29T12:14:51.381259-06:00 ll-chiptest01 xinetd[2021]: IPv6 socket creation failed for service chiptest, trying IPv4 2014-01-29T12:14:51.381271-06:00 ll-chiptest01 xinetd[2021]: Reconfigured: new=0 old=1 dropped=0 (services) The xinetd man page explicitly states that on SIGHUP it "re-reads the configuration file and terminates the servers for services that are no longer available." Later that same section states "If the number of server instances is lowered, some arbitrarily picked servers will be killed to satisfy the limit". In cases where neither of those conditions is true, it seems implicit that no signal should be delivered to the existing child processes, but this is not the case. The implication of this is if a user wishes to make any change to a xinetd configuration, getting the new configs to be read must be done at cost of killing *all* running xinetd children. Given the man page cited above, this was unexpected and resulted in a minor production outage.