Luca wrote:
> > Ok, I have found the problem, I think. There's some ugly interaction
> > between LPRng's lpd and LDAP, specifically libnss-ldap.  This is
> > interesting...
> >
> > With nsswitch.conf like this, lpd doesn't write() into the pipe.
> >
> > passwd: files ldap
> > shadow: files ldap
> > group: files ldap
> >
> > Removing ldap from the above lines causes lpd to work correctly.

Patrick wrote:
> This is totally insane...

Yeah :)

Finally had some time to return to the lprng+ldap problem.  I have done
some more debugging and have discovered the following: lpd is closing
a file descriptor when it shouldn't be!!!

Not attached, you will find an strace, the corresponding debug4 log file,
and a text file containing my analysis of the first two.  I can send
them to you (or anybody else on this list) if you wish.

This is the summary of those three files:

16310 lpd (non-daemon) starts
      libnss-ldap opens a socket that isn't closed (fd 5)
      forks into daemon mode (16311) with ldap socket open (fd 5)

16311 lpd 'Waiting' (daemon) starts
      forks to start ldap SERVICEALL (16312) with ldap socket open (fd 5)

16312 lpd 'SERVICEALL' starts
      closes fd 5 (this is where everything goes wrong)
      opens two tempfiles:
        tempfile1 with fd 5
        tempfile2 with fd 6
      opens pipe3 with fds 7,8
      forks to exec printcap filter (16313) with fd 5 set to tempfile1
      closes fd 8 (will only read from pipe3)

16313 lpd 'printcap filter' starts
      reads/writes ldap stuff into fd 5 (very bad)
        libnss-ldap expects fd 5 to still be the ldap socket
      closes fd 5 (also very bad)
      opens new connection to ldap server on fd 5
        (since the other one got closed)
      dups 5,0  stdin  set to ldap socket (again, very bad)
      dups 6,1  stdout set to tempfile2   (just fine)
      dups 8,2  stderr set to pipe3 write (just fine)
      execs printcap filter with fd 5 fubared

When 16312 calls Make_lpd_call, it does so with: 
  [16312] LPD_CALL  Make_lpd_call: fd 0 -> 0
  [16312] LPD_CALL  Make_lpd_call: fd 1 -> 1
  [16312] LPD_CALL  Make_lpd_call: fd 2 -> 2
  [16312] LPD_CALL  Make_lpd_call: fd 11 -> 3
  [16312] LPD_CALL  Make_lpd_call: fd 13 -> 4

Any mention of fd 5 is lost, so 16313 is happy to close it!

This problem exists with the other filters also (e.g., of), in the case
where I use a normal printcap file rather than a printcap filter.

Any help you can give me on this problem is much appreciated.

Thanks, Luca

--
Luca Filipozzi, ECE Dept. IT Manager, University of British Columbia
Office: MacLeod 257  Voice: 604.822.3976  Web: www.ece.ubc.ca/~lucaf
gpgkey 5A827A2D - A149 97BD 188C 7F29 779E  09C1 3573 32C4 5A82 7A2D

-----------------------------------------------------------------------------
YOU MUST BE A LIST MEMBER IN ORDER TO POST TO THE LPRNG MAILING LIST
The address you post from MUST be your subscription address

If you need help, send email to [EMAIL PROTECTED] (or lprng-requests
or lprng-digest-requests) with the word 'help' in the body.  For the impatient,
to subscribe to a list with name LIST,  send mail to [EMAIL PROTECTED]
with:                           | example:
subscribe LIST <mailaddr>       |  subscribe lprng-digest [EMAIL PROTECTED]
unsubscribe LIST <mailaddr>     |  unsubscribe lprng [EMAIL PROTECTED]

If you have major problems,  send email to [EMAIL PROTECTED] with the word
LPRNGLIST in the SUBJECT line.
-----------------------------------------------------------------------------

Reply via email to