> From [EMAIL PROTECTED] Fri Mar 29 22:35:52 2002
> Date: Fri, 29 Mar 2002 21:35:28 -0800
> From: Luca Filipozzi <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: Re: LPRng: lpd_printcap_path=|/some/filter
>
> 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!!!
Ummm.... no no no - the LDAP code is LEAVING a file descriptor open!
>
> 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)
<froth>
EVIL!!! EVIL!!! This means that there is a 'hidden' file
descriptor open. This was also the case at one time with the
&*()()*& locale support code that OPENED a file descriptor
and NEVER USED IT... And then opened another one... and another
one... GRR... That is the reason for all of the &*))(&* 'how many
file descriptors do I have open' checks running through all of
the LPRng code.
There... I feel beter now.
</froth>
This is VERY bad programming. If you fork a process then you have
TWO processes with this file descriptor and if BOTH do a write,
the receiving end will get two requests and will then reply.
The problem is that the order of the process that reads the reply
and processes it now becomes dependent on various system dependencies.
So:
A -> req
B -> req
C ->reply for A
C ->reply for B
A is delayed...
B reads reply for A
A reads reply for B
It is STRONLY recommended that programs/libraries such as this
CLOSE the connection after using it just for this reason.
I would suggest that this is bug in the LDAP implementation code.
:-) Not that I have such errors in my code... of course... :-)
>
> 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.
-----------------------------------------------------------------------------
