Bad file desriptors with SuSE-7.3 / samba-2.2.3a

[wolfgang.glas at ev-i.at]

Dear Jeremy,

  I further tracked down my problem with bad file escriptors and 
introduced a log print as follows:

cd /usr/src/packages/BUILD/samba-2.2.3a/source/smbd/
diff -c fileio.c.orig fileio.c
*** fileio.c.orig       Sun Feb  3 01:46:55 2002
--- fileio.c    Fri Apr 19 15:36:17 2002
***************
*** 49,54 ****
--- 49,57 ----
      errno = 0;
    }
 
+   DEBUG(1,("seek_file: fd = %d, requested pos = %.0f, new pos = %.0f\n",
+         fsp->fd, (double)(pos+offset), (double)seek_ret ));
+ 
    if((seek_ret == -1) || (seek_ret != pos+offset)) {
      DEBUG(0,("seek_file: sys_lseek failed. Error was %s\n", 
strerror(errno) ));
      fsp->pos = -1;

Diff finished at Mon Apr 22 09:06:45

An intersting part of the resulting log file (debug level =1 ), which 
shows all seek operations on our samba server shows, that occasionally 
seek call fail for fd==1. This is despite the fact, that other seeks on fd 
1 succeed without problems. Using fd 1 seems also to be the right 
behaviour from the kernel/glibc, because samba closes stdin,stdout and 
stderr, when forking off a child for handling a client.

(kernel: 2.4.16 from SuSE, glibc-2.2.4, snipped log file attached)

Does anybody have a clue, what's going wrong here ? glibc doing some magic 
with fd==1, even if it's not associated with stdout ? A samba bug ?

Regards,

  Wolfgang


--
Dr. Wolfgang Glas                        EV-i Informationstechnologie 
GmbH.
Geschäftsführer                          Sebastian-Kneipp-Weg 17
Wolfgang.Glas at ev-i.at                    A-6020 Innsbruck/Austria
phone: ++43-512-284883-2                 fax: ++43-512-281624-31
-------------- next part --------------
A non-text attachment was scrubbed...
Name: log.smbd.short2.bz2
Type: application/octet-stream
Size: 14967 bytes
Desc: not available
Url : http://lists.samba.org/archive/samba-technical/attachments/20020422/142e4fe2/log.smbd.short2.obj