Your message dated Tue, 09 May 2006 04:47:08 -0700
with message-id <[EMAIL PROTECTED]>
and subject line Bug#342559: fixed in xinetd 1:2.3.14-1
has caused the attached Bug report to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere.  Please contact me immediately.)

Debian bug tracking system administrator
(administrator, Debian Bugs database)

--- Begin Message ---
Package: xinetd
Version: 2.3.13-3

I noticed that sometimes services started failing. I tracked this down to
the fact that xinetd passed a closed file as stdout.

The next piece of strace log demonstrates the problem:
[ I did try to make it a bit more readable ]

The trace starts by xinetd waiting for a connection:

1988  select(25, [3 5 8 9 10 22 23 24], NULL, NULL, NULL <unfinished ...>
20950 <... rt_sigaction resumed> {SIG_IGN}, 8) = 0
20950 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
20950 close(3)                          = 0
20950 close(4)                          = 0
20950 close(0)                          = 0
20950 close(1)                          = 0
20950 close(2)                          = 0
20950 setgid32(0)                       = 0
20950 setgroups32(0, [])                = 0
20950 setuid32(0)                       = 0
20950 rt_sigaction(SIGALRM, .......
20950 getsockname(6, {sa_family=AF_INET, sin_port=htons(21),
                             sin_addr=inet_addr("193.1.1.3")}, [16]) = 0
20950 socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 0
20950 bind(0, {sa_family=AF_INET, sin_port=htons(0),
                             sin_addr=inet_addr("193.1.1.3")}, 16) = 0
20950 fcntl64(0, F_SETFD, FD_CLOEXEC)   = 0
20950 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
20950 alarm(30)                         = 0
20950 connect(0, {sa_family=AF_INET, sin_port=htons(113),
                            sin_addr=inet_addr("193.1.1.170")}, 128) = 0
20950 write(0, "7909,21\r\n", 9)        = 9
20950 read(0, 0x8067240, 1024)          = -1 ECONNRESET
20950 time([1133858142])                = 1133858142
20950 getpid()                          = 20950
20950 rt_sigaction(SIGPIPE, {0x40160210, [], SA_RESTORER,
                           0x400b56f8}, {SIG_DFL}, 8) = 0
----> Here is where the trouble starts. syslog has been restarted and the
      syslog socket is no longer connected! So xinetd closes down the old
      connection and opens a new one. Very good... except for the fact
      that the descriptors 0-2 were already closed in preparation of starting
      the service!
 
20950 send(7, "<27>Dec  6 09:35:42 xinetd[20950"..., 79, 0) = -1 ENOTCONN
20950 close(7)                          = 0
20950 socket(PF_FILE, SOCK_DGRAM, 0)    = 1
20950 fcntl64(1, F_SETFD, FD_CLOEXEC)   = 0
20950 connect(1, {sa_family=AF_FILE, path="/dev/log"}, 16) = 0
20950 send(1, "<27>Dec  6 09:35:42 xinetd[20950"..., 79, 0) = 79
20950 rt_sigaction(SIGPIPE, {SIG_DFL}, NULL, 8) = 0
20950 alarm(0)                          = 30
20950 rt_sigaction(SIGALRM, {SIG_DFL}, {0x804f410, [ALRM],
                          SA_RESTORER|SA_RESTART, 0x400b56f8}, 8) = 0
20950 close(0)                          = 0
20950 fcntl64(6, F_SETFD, 0)            = 0
20950 dup2(6, 0)                        = 0
20950 dup2(6, 1)                        = 1
20950 dup2(6, 2)                        = 2
20950 setrlimit(RLIMIT_NOFILE, {rlim_cur=1024, rlim_max=1024}) = 0
20950 close(6)                          = 0
20950 setsid()                          = 20950

------> Now watch it! This is the msg_suspend() function in action. It
        closes the log socket which now happens to be stdout for the ftp
        service....

20950 close(1)                          = 0
20950 execve("/usr/sbin/in.ftpd", ["in.ftpd"], [/* 243 vars */]) = 0
20950 uname({sys="Linux", node="ah1039", ...}) = 0
20950 brk(0)                            = 0x805be6c



So the problem is that there is a period that the so carefully closed 
filedescriptors can be re-used. I tried to prevent it by the following
patch. The trick is to reopen them to /dev/null. So all history is
abandoned but the descriptors cannot be recaimed.

==== Patch =====

Index: child.c
===================================================================
--- child.c     (revision 4)
+++ child.c     (revision 17)
@@ -271,6 +271,7 @@
    connection_s            *cp  = SERVER_CONNECTION( serp ) ;
    struct service_config   *scp = SVC_CONF( sp ) ;
    const char              *func = "child_process" ;
+   int                     fd, null_fd;
 
    signal_default_state();
 
@@ -283,11 +284,24 @@
    signals_pending[0] = -1;
    signals_pending[1] = -1;
 
-   Sclose(0);
-   Sclose(1);
-   Sclose(2);
+   if ( ( null_fd = open( "/dev/null", O_RDONLY ) ) == -1 )
+   {
+      msg( LOG_ERR, func, "open('/dev/null') failed: %m") ;
+      _exit( 1 ) ;
+   }
 
+   for ( fd = 0 ; fd <= MAX_PASS_FD ; fd++ )
+   {
+      if ( fd != null_fd && dup2( null_fd, fd ) == -1 )
+      {
+         msg( LOG_ERR, func, "dup2(%d, %d) failed: %m") ;
+         _exit( 1 ) ;
+      }
+   }
+   if ( null_fd > MAX_PASS_FD )
+      (void) Sclose( null_fd ) ;
 
+
 #ifdef DEBUG_SERVER
    if ( debug.on )
    {


Regards,

Leo Weppelman.

Attachment: signature.asc
Description: Digital signature


--- End Message ---
--- Begin Message ---
Source: xinetd
Source-Version: 1:2.3.14-1

We believe that the bug you reported is fixed in the latest version of
xinetd, which is due to be installed in the Debian FTP archive:

xinetd_2.3.14-1.diff.gz
  to pool/main/x/xinetd/xinetd_2.3.14-1.diff.gz
xinetd_2.3.14-1.dsc
  to pool/main/x/xinetd/xinetd_2.3.14-1.dsc
xinetd_2.3.14-1_i386.deb
  to pool/main/x/xinetd/xinetd_2.3.14-1_i386.deb
xinetd_2.3.14.orig.tar.gz
  to pool/main/x/xinetd/xinetd_2.3.14.orig.tar.gz



A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to [EMAIL PROTECTED],
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Thomas Seyrat <[EMAIL PROTECTED]> (supplier of updated xinetd package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing [EMAIL PROTECTED])


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.7
Date: Tue,  9 May 2006 13:32:06 +0200
Source: xinetd
Binary: xinetd
Architecture: source i386
Version: 1:2.3.14-1
Distribution: unstable
Urgency: low
Maintainer: Thomas Seyrat <[EMAIL PROTECTED]>
Changed-By: Thomas Seyrat <[EMAIL PROTECTED]>
Description: 
 xinetd     - replacement for inetd with many enhancements
Closes: 309312 312663 336023 342448 342559 342724
Changes: 
 xinetd (1:2.3.14-1) unstable; urgency=low
 .
   * New upstream release (closes: #342724).
   * Updated config.guess and config.sub (closes: #342448).
   * Comment about log_on_* in xinetd.conf (closes: #312663).
   * Patch by Leo Weppelman <[EMAIL PROTECTED]> on child.c
     (closes: #342559)
   * Patch for xconv.pl by Ron Murray <[EMAIL PROTECTED]> to
     process "#<off>#" lines (closes: #336023).
   * Added configuration file for discard internal service
     (closes: #309312)
   * Bumped Standards-Version to 3.7.2
   * Bumped debhelper compatibility level to 5.
Files: 
 556c078061f6a690270b02814f2f9d87 579 net extra xinetd_2.3.14-1.dsc
 567382d7972613090215c6c54f9b82d9 301703 net extra xinetd_2.3.14.orig.tar.gz
 49c963f322ade3760bbcc3e00a367967 36322 net extra xinetd_2.3.14-1.diff.gz
 a804e25e8af2bc57b8ae6b25baf6a122 137446 net extra xinetd_2.3.14-1_i386.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)

iD8DBQFEYH/SG7q+HrSg3okRAgeUAJ9Cvq9f49875Rvn8RMSgov+UQnOuACeLtUK
SSmeyrRUKWaXoocrud0HOCM=
=aVNU
-----END PGP SIGNATURE-----


--- End Message ---

Reply via email to