Bug#274333: libgnomeprint 2.8.0 breaks gpdf

[Loïc Minier]

Loïc Minier <lool@dooz.org> - Wed, Oct 06, 2004:

>     bee# netstat -anp | grep 631
>     tcp        0      0 0.0.0.0:631             0.0.0.0:*              =
 LISTEN     2993/rpc.statd      

 Could people reading this and experiencing the problem check wether
 they have something listening on TCP port 631?

 If they do, what is it? cupsd? rpc.statd? something else?

 If there's nothing listening there, does the gpdf freeze still happen?

     Conclusions:

 I think I am experiencing the first type of bug, which can be described
 as:
 if something is listening on TCP port 631 (a simple netcat for
 example), and you use gpdf, some lib it uses will contact TCP port 631
 and timeout.
   This should be fixed by finding the culprit and telling it not to
 contact port 631 if it has no clue that a CUPS server might run there.
   This is only happening if you don't have cupsys on your system.

 Another possible bug I am not experiencing is that:
 cupsd is running and listening on TCP port 631, but is not responding
 (in a timely manner or not responding correctly or not repsonding at
 all) to a request made on port 631 by a lib used by gpdf.
   The same fix as above applies, but we also need to fix a bug in CUPS
 for such requests.
   This can only happen if you have cupsys on your system.

 Or the bug also happens when nothing listens on TCP port 631, and this
 is a completely different bug than mine, but mine still has to be
 resolved.
   This can only happen wether you have cupsys on your system or not.

>  I have no idea why rpc.statd uses 631, right now I suggest stopping NF=
S
>  as a workaround.

 For your information, rpc.statd contacts portmap to get a port
 assigned.  portmap uses svctcp_create to create such a socket.
 svctcp_create is implemented in libc6 which calls bindresvport to get a
 socket on a priviledged port.  The port is choosen between 600 and
 1023, starting with port = (__getpid () % 424) + 600, then checking
 each port until an unused port is found (it wraps around at 1023).

   Regards,

-- 
Loïc Minier <lool@dooz.org>