Bug 54565
| Summary: | kill -USR2 drops all services | ||
|---|---|---|---|
| Product: | [Retired] Red Hat Linux | Reporter: | David Thompson <thomas> |
| Component: | xinetd | Assignee: | Trond Eivind Glomsrxd <teg> |
| Status: | CLOSED RAWHIDE | QA Contact: | Brock Organ <borgan> |
| Severity: | high | Docs Contact: | |
| Priority: | medium | ||
| Version: | 7.1 | CC: | bbraun |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | i386 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2001-12-04 15:52:48 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
I'll test it this week. 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
Can you try the test rpms at http://people.redhat.com/teg/xinetd/ ? 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. 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 Yes, the 2001-12-03 development version works for us. Thanks much. Dave Thompson UW-Madison Computer Sciences It's in Rawhide, as xinetd-2.3.4-0.2 |
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: