Bug 54565 - kill -USR2 drops all services
kill -USR2 drops all services
Status: CLOSED RAWHIDE
Product: Red Hat Linux
Classification: Retired
Component: xinetd (Show other bugs)
7.1
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Trond Eivind Glomsrxd
Brock Organ
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-10-12 11:33 EDT by David Thompson
Modified: 2007-04-18 12:37 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-12-04 10:52:48 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description David Thompson 2001-10-12 11:33:47 EDT
From Bugzilla Helper:
User-Agent: Mozilla/4.78 [en] (X11; U; Linux 2.4.6-csl1smp i686)

Description of problem:
If the instances and banner_fail parameters are specified for a service,
sending SIGUSR2 to xinetd after the maximum number of instances has been
exceeded causes xinetd to close all listening sockets and kill all running
instances.  Sending SIGUSR2 again will cause xinetd to re-open the
listening sockets.  Not specifying a banner_fail work fine.

Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1.  Create an xinetd service like:
service ftp
{
      id                = ftp
      socket_type       = stream
      protocol          = tcp
      wait              = no
      instances         = 5
      user              = root
        server          = /usr/local/bin/vsftpd
	banner_fail     = <some banner file>
}

2.  Try to start 6 ftp sessions to the host.  The last one fails.

3. run /etc/rc.d/init.d/xinetd reload.

4. Examine the running xinetd process with lsof.  No listening sockets, and
all the ftp servers went bye-bye.

5. run /etc/rc.d/init.d/xinetd reload

6. Look at lsof again.  The listening sockets are there again.
	

Additional info:
Comment 1 Trond Eivind Glomsrxd 2001-10-15 15:39:46 EDT
I'll test it this week.
Comment 2 David Thompson 2001-10-18 14:37:12 EDT
I ran strace on the xinetd process, and it shows a little more about what's
happening.  In the case where banner_fail is specified, the sequence after the
signal is delivered looks like:

821   select(15, [4 5 6 7 8 9 10 11 12 13 14], NULL, NULL, NULL) = ? ERESTARTNOH
AND (To be restarted)
821   --- SIGUSR2 (User defined signal 2) ---
821   sigreturn()                       = ? (mask now [])
821   time([1003428179])                = 1003428179
821   getpid()                          = 821
821   rt_sigaction(SIGPIPE, {0x401672a8, [], 0x4000000}, {SIG_IGN}, 8) = 0
821   send(3, "<29>Oct 18 13:02:59 xinetd[821]:"..., 57, 0) = 57
821   rt_sigaction(SIGPIPE, {SIG_IGN}, NULL, 8) = 0
821   open("/etc/xinetd.conf", O_RDONLY) = 15
821   rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
821   rt_sigprocmask(SIG_BLOCK, [ALRM VTALRM PROF], NULL, 8) = 0
821   gettimeofday({1003428179, 914090}, NULL) = 0
821   setitimer(ITIMER_REAL, {it_interval={0, 0}, it_value={60, 0}}, NULL) = 0
821   rt_sigprocmask(SIG_UNBLOCK, [ALRM VTALRM PROF], NULL, 8) = 0
821   rt_sigprocmask(SIG_BLOCK, [ALRM VTALRM PROF], NULL, 8) = 0
821   setitimer(ITIMER_REAL, {it_interval={0, 0}, it_value={0, 0}}, NULL) = 0
821   rt_sigprocmask(SIG_UNBLOCK, [ALRM VTALRM PROF], NULL, 8) = 0
821   close(15)                         = 0

after this it starts closing down all the listening sockets.  Note that it never
reads the config file.

When no banner_fail is specified, it reads the file like it should:

821   select(15, [4 5 6 7 8 9 10 11 12 13 14], NULL, NULL, NULL) = ? ERESTARTNOH
AND (To be restarted)
821   --- SIGUSR2 (User defined signal 2) ---
821   sigreturn()                       = ? (mask now [])
821   time([1003428308])                = 1003428308
821   getpid()                          = 821
821   rt_sigaction(SIGPIPE, {0x401672a8, [], 0x4000000}, {SIG_IGN}, 8) = 0
821   send(3, "<29>Oct 18 13:05:08 xinetd[821]:"..., 57, 0) = 57
821   rt_sigaction(SIGPIPE, {SIG_IGN}, NULL, 8) = 0
821   open("/etc/xinetd.conf", O_RDONLY) = 15
821   rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
821   rt_sigprocmask(SIG_BLOCK, [ALRM VTALRM PROF], NULL, 8) = 0
821   gettimeofday({1003428308, 599995}, NULL) = 0
821   setitimer(ITIMER_REAL, {it_interval={0, 0}, it_value={60, 0}}, NULL) = 0
821   rt_sigprocmask(SIG_UNBLOCK, [ALRM VTALRM PROF], NULL, 8) = 0
821   fstat64(15, {st_mode=S_IFREG|0644, st_size=2314, ...}) = 0
821   lseek(15, 0, SEEK_CUR)            = 0
821   fcntl64(15, F_GETFL)              = 0 (flags O_RDONLY)
821   read(15, "#\n# xinetd.conf file\n# created f"..., 8192) = 2314
<...snip...>

Just some more useful information.

Dave


Comment 3 Trond Eivind Glomsrxd 2001-11-30 19:18:36 EST
Can you try the test rpms at http://people.redhat.com/teg/xinetd/ ?
Comment 4 Rob Braun 2001-12-02 22:16:01 EST
I'm able to reproduce it with the latest test versions.  This is odd, and I'm 
still trying to track it down.  It only happens with banner_fail, and 
banner_fail doesn't seem to be doing anything bad.
Comment 5 Rob Braun 2001-12-03 16:26:35 EST
Ok, this was because the banner_* routines were using the sio routines 
(apparently) incorrectly.  This should be fixed in 
http://www.xinetd.org/devel/xinetd-2001.12.03.tar.gz
Comment 6 David Thompson 2001-12-04 10:52:40 EST
Yes, the 2001-12-03 development version works for us.  Thanks much.

Dave Thompson
UW-Madison Computer Sciences
Comment 7 Trond Eivind Glomsrxd 2001-12-06 11:53:10 EST
It's in Rawhide, as xinetd-2.3.4-0.2

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