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.