Bug 1075152 - modify the xinetd man page to make it more clear on what happens to services on xinetd reload
Summary: modify the xinetd man page to make it more clear on what happens to services ...
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: man-pages-overrides   
(Show other bugs)
Version: 6.6
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: rc
: ---
Assignee: Jan Chaloupka
QA Contact: Iveta Wiedermann
URL:
Whiteboard:
Keywords: EasyFix, ManPageChange, Patch
Depends On:
Blocks: 994246 1119317 1146259
TreeView+ depends on / blocked
 
Reported: 2014-03-11 15:16 UTC by Dave Sullivan
Modified: 2018-12-09 17:37 UTC (History)
6 users (show)

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: ---


Attachments (Terms of Use)
warning of xinitd reload termination handling (1.03 KB, patch)
2014-06-04 12:41 UTC, Jan Chaloupka
no flags Details | Diff
warning of xinitd reload termination handling (1.03 KB, patch)
2014-06-12 10:38 UTC, Jan Chaloupka
no flags Details | Diff


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2014:1382 normal SHIPPED_LIVE man-pages-overrides bug fix update 2014-10-14 01:21:54 UTC

Description Dave Sullivan 2014-03-11 15:16:52 UTC
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.

Comment 2 Jan Chaloupka 2014-06-04 12:41:25 UTC
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.

Comment 3 Jan Synacek 2014-06-11 06:50:26 UTC
The patch looks reasonable. But, please, s/deadling/dealing/.

Comment 4 Jan Chaloupka 2014-06-12 10:38:49 UTC
Created attachment 908063 [details]
warning of xinitd reload termination handling

Done

Comment 5 Jan Synacek 2014-06-13 06:11:26 UTC
Thanks for the patch!

Comment 6 Dave Sullivan 2014-07-07 22:06:06 UTC
Looks good to me. Thx.

Comment 12 Jan Chaloupka 2014-08-20 07:48:57 UTC
Hello, Dave,

should we clone this bug for rhel7.1?

Comment 13 Dave Sullivan 2014-09-24 21:06:54 UTC
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.

Comment 14 errata-xmlrpc 2014-10-14 07:26:59 UTC
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


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