From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020401 Description of problem: With Enigma and earlier, one could toggle xinetd maintained services with just chkconfig. "chkconfig wu-ftpd on" would not just create the proper links for the current run-level, but would also send a USR2 signal to xinetd, causing a hard reconfiguration and wu-ftpd being enabled. The exact opposite would happen for "chkconfig wu-ftpd off". It would create the run-level link and signal xinetd to re-read its config, stopping listening on the wu-ftpd port. Besides the change from SIGUSR2 to SIGHUP, I see a major (still undocumented) difference on Skipjack beta2. "chkconfig wu-ftpd on" does NOT signal xinetd to re-read its config. But "chkconfig wu-ftpd off" still does. Unless this is a bug, it should be documented somewhere (the documentation for Enigma was wrong), that "chkconfig wu-ftpd on" is not the opposite of "chkconfig wu-ftpd off" and probably other xinetd maintained services: # service xinetd status xinetd (pid 2337) is running... # chkconfig --list wu-ftpd wu-ftpd off # chkconfig wu-ftpd on [log: xinetd: xinetd -HUP succeeded] # chkconfig --list wu-ftpd wu-ftpd on # socklist | grep xinetd At this point -- unlike Enigma or earlier -- xinetd would not listen on ftp port yet. # service xinetd restart [log: xinetd: xinetd shutdown succeeded xinetd[2462]: xinetd Version 2002.03.26 started with libwrap options compiled in. xinetd[2462]: Started working: 1 available service xinetd: xinetd startup succeeded] # socklist | grep xinetd tcp 21 13110 0 2462 5 xinetd This disables and stops it: # chkconfig wu-ftpd off [log: xinetd[2462]: Starting reconfiguration xinetd[2462]: service ftp deactivated xinetd[2462]: Reconfigured: new=0 old=0 dropped=1 (services) xinetd: xinetd -HUP succeeded] # socklist | grep xinetd # This enables it, but doesn't turn it on: # chkconfig wu-ftpd on [log: xinetd: xinetd -HUP succeeded] # socklist | grep xinetd # Version-Release number of selected component (if applicable): xinetd 2.3.4-0.6 (plus chkconfig 1.3.4-1) How reproducible: Always
It didn't send signals, but it does exec '/etc/inet.d/xinetd reload'.
Signal seems to be sent... taking back the bug :)
Confirmed as working on two systems, with xinetd-2.3.4-0.7 and xinetd-2.3.4-0.8. No changes in that part.
Verified. # rpm -q xinetd xinetd-2.3.4-0.8
It's patch1 that fixes this bug.