Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
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
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.
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.
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.