Launchpad has imported 77 comments from the remote bug at https://bugzilla.redhat.com/show_bug.cgi?id=103401.
If you reply to an imported comment from within Launchpad, your comment will be sent to the remote bug automatically. Read more about Launchpad's inter-bugtracker facilities at https://help.launchpad.net/InterBugTracking. ------------------------------------------------------------------------ On 2003-08-29T20:13:45+00:00 sbonnevi wrote: Description of problem: On boot, ypbind occasionally grabs port 631/udp, blocking CUPS from binding to the port. This is a glibc problem because ypbind is a RPC service that has its port assigned dynamically through bindresvport(). The code in libc/sunrpc/bindrsvprt.c shows the port number is assigned purely based on the PID of the ypbind process, something like port = (PID % 424) + 600 The PID seems to vary slightly from reboot to reboot, but generally is in the 870s on the machine in question, resulting in ports assigned in the vicinity of 630. CUPS (actually, IPP) has ports 631/tcp and 631/udp reserved. NIS starts first, so it wins, and since CUPS has a reserved Well Known Port, it can't relocate and loses. Version-Release number of selected component (if applicable): glibc-2.3.2-27.9 How reproducible: Depends entirely on the PID handed to ypbind on boot, and the exact set of services configured affects this. Suggested Fix: The glibc algorithm already blacklists all reserved ports below 600, presumably to avoid this exact problem. Consider altering the code to blacklist 5 to 8 additional ports in the 600-1023 range that are or may be in common use: 631 (IPP == CUPS) 636 (LDAPS) 749 (Kerberos V kadmin) 873 (rsyncd) 992-995 (SSL-enabled telnet, IMAP, IRC, and POP3) The ports lost could be recovered, if desired, by allowing ports in the 590-600 range to be assigned by bindrsvprt(). Reply at: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/304393/comments/0 ------------------------------------------------------------------------ On 2003-09-01T21:43:29+00:00 jakub wrote: According to Ulrich Drepper, daemons requiring specific ports in the 600-1023 range need to be started before any daemons using bindresvport. Reply at: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/304393/comments/1 ------------------------------------------------------------------------ On 2003-09-02T16:29:53+00:00 twaugh wrote: I think that portmap ought to be tought how to avoid a list of ports. Otherwise, once I've stopped cupsd (for whatever reason) and restarted ypbind, I can no longer be sure that cupsd will ever start again. Reply at: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/304393/comments/2 ------------------------------------------------------------------------ On 2003-09-02T21:06:25+00:00 twaugh wrote: (see above comment) Reply at: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/304393/comments/3 ------------------------------------------------------------------------ On 2003-09-03T06:04:59+00:00 sbonnevi wrote: If you accept Ulrich's argument that this is a service bug, then this is NOT just a CUPS bug. It's also a bug against xinetd-2.3.12-0.3E, openldap-2.0.27-9, and krb5-server-1.2.7-15. ALL of the services in the distribution that I know about that use Well Known Ports in the 600-1023 range start up AFTER ypbind, not before! Reply at: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/304393/comments/4 ------------------------------------------------------------------------ On 2003-09-03T15:04:29+00:00 twaugh wrote: This problem should be solved in portmap. Here is a proof-of-concept, which I think should be merged into portmap: http://cyberelk.net/tim/portreserve. In summary: portmap should read a directory of configuration files, one per daemon, each containing the name of the service that is out of bounds. (I know that bindresvport is the culprit, but what other users of that are there really?) Reply at: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/304393/comments/5 ------------------------------------------------------------------------ On 2003-11-15T00:51:46+00:00 sbonnevi wrote: I'm moving this to RHEL 3 because we're still seeing this in operation on servers with that version installed. I don't know what else uses bindresvport, if anything, I just know that if you have ypserv and CUPS running, there's a pretty decent chance of a collision on boot which breaks CUPS. Reply at: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/304393/comments/6 ------------------------------------------------------------------------ On 2003-12-24T10:32:08+00:00 jorton wrote: spamassassin's spamd is another possible collision (though not in RHEL), it uses port 783 by default. Reply at: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/304393/comments/7 ------------------------------------------------------------------------ On 2004-01-07T04:50:06+00:00 aleksey wrote: *** Bug 83985 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/304393/comments/8 ------------------------------------------------------------------------ On 2004-01-15T16:40:41+00:00 twaugh wrote: *** Bug 113586 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/304393/comments/9 ------------------------------------------------------------------------ On 2004-01-16T20:09:27+00:00 minelli wrote: NFS also causes port collisions, more specifically rpc.rquotad. Reply at: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/304393/comments/10 ------------------------------------------------------------------------ On 2004-05-12T16:35:31+00:00 orion wrote: I just had a collision between rpc.mountd and cups. Reply at: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/304393/comments/11 ------------------------------------------------------------------------ On 2004-07-20T19:42:40+00:00 aoliva wrote: Regarding command #1 (daemons requiring specific ports in the 600-1023 range need to be started before any daemons using bindresvport): if you consider that ypbind (that uses bindresvport) is often necessary to obtain user information, host information, service port numbers, etc, and that starting services that require such information before it's available won't work, we've got a catch 22 situation. We really need a better way to reserve ports such that portmap doesn't take them over. portreserve looks like a perfect solution for the problem, except that it can't rely on th ypbind services map, so there's a slight risk that it might reserve a port based on /etc/services that turns out to be different in the NIS map, or even that the port number can't be identified because it's only defined in the services map. I suppose it's a resonable requirement to have any ports that are to be reserved by portreserve defined in /etc/services or some other database that's available early enough in the boot. Reply at: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/304393/comments/12 ------------------------------------------------------------------------ On 2004-08-05T21:07:37+00:00 notting wrote: *** Bug 125962 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/304393/comments/13 ------------------------------------------------------------------------ On 2004-08-12T18:22:48+00:00 steved wrote: reassing to Jakub the glibc maintainer Reply at: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/304393/comments/14 ------------------------------------------------------------------------ On 2004-09-28T05:54:01+00:00 drepper wrote: This is no glibc issue. Lacking a better idea, I'll assign it to initscripts since a solution à la portreserve would be part of initscripts. Changing bindresvport() is no option since there are no universally available ports (look at the IANA list). So an extern solution like portreserve is needed. I think it can work nicely and should not be hard the integrate. Reply at: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/304393/comments/15 ------------------------------------------------------------------------ On 2005-02-04T16:34:14+00:00 bruce_friedman wrote: I am seeing a similar issue now on Fedora Core 3 where rpc.mountd grabs port 783 before spamassassin has a chance to grab it. Need to move nfs init sequence from 60 to 81 to place it after spamassassin to clear the problem. Should the port be reserved, or is rearrangement of init order more appropriate? Reply at: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/304393/comments/16 ------------------------------------------------------------------------ On 2005-03-15T14:47:32+00:00 sbonnevi wrote: As an update, and not that it should be a surprise since nothing has been changed, but we are seeing the exact issue I originally reported (on Red Hat Linux 9, as I recall) on Red Hat Enterprise Linux 4 as well. Reply at: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/304393/comments/17 ------------------------------------------------------------------------ On 2005-07-16T21:25:39+00:00 raines wrote: Just want to add that I have seen this on several RHEL4 clients too. Also, having ypbind start AFTER other services is not an option as ypbind is needed to see all accounts and many services need to see those accounts when starting (e.g.imapd for port 993) Reply at: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/304393/comments/18 ------------------------------------------------------------------------ On 2005-07-29T01:12:58+00:00 minelli wrote: Is this ever going to be fixed? This is a wide spread problem that will affect almost everyone at some point.... Reply at: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/304393/comments/19 ------------------------------------------------------------------------ On 2005-07-29T01:13:49+00:00 minelli wrote: Is this ever going to be fixed? This is a wide spread problem that will affect almost everyone at some point.... Reply at: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/304393/comments/20 ------------------------------------------------------------------------ On 2005-07-29T18:03:48+00:00 jdennis wrote: *** Bug 154800 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/304393/comments/21 ------------------------------------------------------------------------ On 2005-09-15T19:09:52+00:00 rc040203 wrote: I would propose to make this issue a release blocker for FC5. Reply at: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/304393/comments/22 ------------------------------------------------------------------------ On 2005-09-21T21:33:54+00:00 notting wrote: This problem is being considered for a future major release of Red Hat Enterprise Linux. Red Hat does not currently plan to provide a resolution for this in a Red Hat Enterprise Linux update for currently deployed systems. With the goal of minimizing risk of change for deployed systems, and in response to customer and partner requirements, Red Hat takes a conservative approach when evaluating changes for inclusion in maintenance updates for currently deployed products. The primary objectives of update releases are to enable new hardware platform support and to resolve critical defects. Reply at: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/304393/comments/23 ------------------------------------------------------------------------ On 2005-09-29T19:07:54+00:00 notting wrote: *** Bug 51904 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/304393/comments/24 ------------------------------------------------------------------------ On 2005-10-17T13:02:42+00:00 jss wrote: I reported this some time ago in http://sources.redhat.com/bugzilla/show_bug.cgi?id=1014 glibc seems the obvious place to fix this problem. Reply at: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/304393/comments/25 ------------------------------------------------------------------------ On 2005-10-17T13:06:08+00:00 jakub wrote: And you were also told there it is a bad idea and glibc is not going to change in this regard. Reply at: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/304393/comments/26 ------------------------------------------------------------------------ On 2005-10-17T13:16:53+00:00 jss wrote: This will be my only comment to prevent bugspam, but it says nowhere in the bug that this is a bad idea, or why it is a bad idea. Please can someone elaborate on this? All these issues are caused by a single point of failure - glibc. It seems the obvious place to solve the issue. It seems pretty hairbrained to have a special daemon to handle this. All the apps, and any 3rd party ones too, need to be rewritten to use the daemon. Why couldn't there be a configuration file stating the ports for bindresvport() to avoid? Reply at: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/304393/comments/27 ------------------------------------------------------------------------ On 2006-01-12T20:45:11+00:00 michael wrote: (In reply to comment #34) > I would propose to make this issue a release blocker for FC5. FYI, I see this problem in FC5 test 1, as reported in 154800 (which was closed as a duplicate of this bug). Reply at: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/304393/comments/28 ------------------------------------------------------------------------ On 2006-04-24T22:17:40+00:00 orion wrote: Perhaps we can reopen this and actually work on a fix? Target FC6? Reply at: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/304393/comments/29 ------------------------------------------------------------------------ On 2006-05-16T15:50:49+00:00 twaugh wrote: *** Bug 191950 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/304393/comments/30 ------------------------------------------------------------------------ On 2006-05-16T15:51:32+00:00 twaugh wrote: *** Bug 189144 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/304393/comments/31 ------------------------------------------------------------------------ On 2006-12-10T15:30:29+00:00 chris wrote: *** Bug 218216 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/304393/comments/32 ------------------------------------------------------------------------ On 2007-05-30T08:12:53+00:00 jengelh wrote: Also see https://bugzilla.novell.com/show_bug.cgi?id=262341 Reply at: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/304393/comments/33 ------------------------------------------------------------------------ On 2007-10-04T15:36:39+00:00 notting wrote: *** Bug 318461 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/304393/comments/34 ------------------------------------------------------------------------ On 2007-10-29T22:19:14+00:00 orion wrote: Seems like leaving this in "Closed Deferred" means it will never get worked on. Is there ever a hope of a fix? Reply at: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/304393/comments/35 ------------------------------------------------------------------------ On 2007-10-30T00:19:35+00:00 smooge wrote: Any bug in RHEL-3 is dead as far as I can tell unless it is a security problem. Reply at: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/304393/comments/36 ------------------------------------------------------------------------ On 2007-10-30T00:33:32+00:00 mgalgoci wrote: This bug is still present in RHEL4U5 as I had a system hit this just a few weeks ago. It may well be present in rhel5 also, though I haven't verified. Reply at: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/304393/comments/37 ------------------------------------------------------------------------ On 2007-10-30T01:09:32+00:00 sbonnevi wrote: It is present in 5 and 5.1; at least some of the bugs marked as duplicates above reflect that. #218216 is the same bug in Fedora Core 6 filed against spamd in spamassassin (port 783), for example, which is effectively RHEL 5 for this purpose. Reply at: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/304393/comments/38 ------------------------------------------------------------------------ On 2007-10-30T02:24:56+00:00 orion wrote: Also present in Fedora 7, which is what got me digging this old thing up again. Now the service is "rpcbind" which acquires the ports. Reply at: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/304393/comments/39 ------------------------------------------------------------------------ On 2007-10-30T09:02:21+00:00 jss wrote: I still haven't seen any technical reasons why it portmap couldn't check in a special directory for files containing reserved ports and not use these. See comment #5. These files could be installed by RPM. Reply at: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/304393/comments/40 ------------------------------------------------------------------------ On 2008-03-11T00:15:36+00:00 borisv wrote: On RHEL-4 we had practically the same problem. The program that listened on the port TCP 631 was rpc.statd. As a result cups died on startup with the message: startListening: Unable to bind socket for address 7f000001:631 - Address already in use. While Red Hat decides what is the best way to fix this permanently can Red Hat offer a workaround? Reply at: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/304393/comments/41 ------------------------------------------------------------------------ On 2008-05-12T15:13:58+00:00 jay wrote: I just got hit with this on rhel4, rpc.statd took port 631, preventing cups from starting. Reply at: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/304393/comments/42 ------------------------------------------------------------------------ On 2008-10-04T02:46:09+00:00 morioka wrote: I got same problem on Fedora 9. krb5kdc port 750. Please fix this. Reply at: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/304393/comments/43 ------------------------------------------------------------------------ On 2008-10-04T02:49:21+00:00 morioka wrote: I got same problem on Fedora 9. krb5kdc port 750. Please fix this. Reply at: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/304393/comments/44 ------------------------------------------------------------------------ On 2008-10-14T15:46:13+00:00 twaugh wrote: The workaround is: use portreserve (see comment #5). This is already included in Fedora 10, and CUPS in Fedora 10 makes use of it in its initscript. spamassassin has been mentioned as another service that could make use of portreserve. Changing component and reassigning. Reply at: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/304393/comments/45 ------------------------------------------------------------------------ On 2008-10-14T16:02:44+00:00 smooge wrote: Can portreserve work with RHEL-4/5? If it can, I would be happy to get it into EPEL as a help. Reply at: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/304393/comments/46 ------------------------------------------------------------------------ On 2008-10-14T16:24:05+00:00 twaugh wrote: Yes, I don't see any reason it wouldn't work. However, services that want to use it need to modify their initscript (to call 'portrelease'). Packaging it for EPEL might help for third-party applications though, and other EPEL packages. Reply at: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/304393/comments/47 ------------------------------------------------------------------------ On 2008-10-14T16:31:48+00:00 jss wrote: Can someone enlighten me how portreserve is not a race condition waiting to happen? As far as I can tell, you get portreserve to release the port before starting the service. How do you make sure nothing else gets in there first before the portreserve command and the service-starting command? I suspect it's unlikely that something could slip in between these commands, but is this good programming? Reply at: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/304393/comments/48 ------------------------------------------------------------------------ On 2008-10-14T16:47:13+00:00 twaugh wrote: (In reply to comment #75) > Can someone enlighten me how portreserve is not a race condition waiting to > happen? As far as I can tell, you get portreserve to release the port before > starting the service. How do you make sure nothing else gets in there first > before the portreserve command and the service-starting command? I suspect > it's > unlikely that something could slip in between these commands, but is this good > programming? Without support in glibc/portmap there is no generic way around this. Reply at: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/304393/comments/49 ------------------------------------------------------------------------ On 2009-01-21T15:15:10+00:00 jay wrote: have any of the portreserve changes in Fedora 10 made it into the RHEL5.3 release? or would this wait until RHEL6? Reply at: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/304393/comments/77 ------------------------------------------------------------------------ On 2009-01-21T15:22:41+00:00 twaugh wrote: It's not in RHEL-5.3. Reply at: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/304393/comments/78 ------------------------------------------------------------------------ On 2009-06-26T16:20:13+00:00 bugzilla wrote: Confirming 5.3 has issues. After updating and rebooting 105 clients with a recent kernel patch + others, one had this issue logged in /var/log/cups/error_log: E [25/Jun/2009:21:11:11 -0400] Unable to bind broadcast socket - Address already in use. Cups didn't get broadcasted print queues until after restarting cups. The curious thing is that I hard-bind rpc services; status, nlockmgr, ypbind are listing on *my* chosen ports, non of the conflicting with cups's 631. We've also had past (but none this time) random issues with rsyncd not being able to bind to its listening port, I'm extrapolating the root cause is the same. Reply at: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/304393/comments/84 ------------------------------------------------------------------------ On 2009-12-03T05:10:52+00:00 wtogami wrote: I'm adding the portreserve hack to spamassassin-3.3.0 for RHEL-6. But this is not a complete solution. Arbitrary other services can still cause this failure. Reply at: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/304393/comments/85 ------------------------------------------------------------------------ On 2009-12-03T09:30:54+00:00 twaugh wrote: Warren: how so? The only way I know of that it can fail is after the protected service is stopped. There's no way to close that hold without kernel support. Reply at: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/304393/comments/86 ------------------------------------------------------------------------ On 2010-02-25T17:46:45+00:00 bugs wrote: Some ethernet NICs (broadcom, intel gigabit) have something called ASF enabled. This causes the NIC to gobble stuff sent to port 623 and port 664! So there are some other ports that we need to exclude. RPC mounts avoid these ports by using sunrpc.min_resvport which is set to 665 these days. So the code for mounts won't use ports below 665. Maybe bindrsvprt.c could be modified to also use sunrpc.min_resvport and sunrpc.max_resvport. In the 623/664 cases there is no collision with another daemon. The affected NICs lose the packets. ypmatch and ypcat will hang with do_ypcall: clnt_call: RPC: Timed out when they pick 623 or 664 on the affected hardware. sshd (particularly when AllowGroups is used) will also hang on the affected hardware when it selects 623 or 664 to do an NIS lookup. A kludge is to use xinetd to grab the 623/664 ports for a workaround. Reply at: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/304393/comments/87 ------------------------------------------------------------------------ On 2010-07-21T11:00:34+00:00 Colin.Simpson wrote: Just been hit with this again: # netstat -anp | grep 631 tcp 0 0 0.0.0.0:631 0.0.0.0:* LISTEN 25591/cupsd udp 0 0 0.0.0.0:631 0.0.0.0:* 24623/rpc.statd Whilst portreserve looks like a fix, from my understanding is it not a bit of a hack around this. Shouldn't portmaper not just be given a list of ports to never use from a file that gets appended to as services are added from packages? Or am I missing something? Reply at: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/304393/comments/88 ------------------------------------------------------------------------ On 2010-07-21T14:20:08+00:00 twaugh wrote: See comment #16. Reply at: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/304393/comments/89 ------------------------------------------------------------------------ On 2010-07-21T14:52:43+00:00 Colin.Simpson wrote: comment #16 doesn't answer why we need portreserve, it just says that there are no free unallocated low ports in the official allocation list. That's true, but shouldn't portmapper have a notion of services THIS system has or needs reserved low and not allocate them. Or is there just no easy way of allocating a low port in a system call that can exclude ports we want to hold back? Sounds like a new call is called for eventually? Reply at: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/304393/comments/90 ------------------------------------------------------------------------ On 2010-11-11T14:59:17+00:00 releng-rhel wrote: Red Hat Enterprise Linux 6.0 is now available and should resolve the problem described in this bug report. This report is therefore being closed with a resolution of CURRENTRELEASE. You may reopen this bug report if the solution does not work for you. Reply at: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/304393/comments/91 ------------------------------------------------------------------------ On 2011-07-06T00:03:48+00:00 pm-rhel wrote: This request was evaluated by Red Hat Product Management for inclusion in the current release of Red Hat Enterprise Linux. Because the affected component is not scheduled to be updated in the current release, Red Hat is unfortunately unable to address this request at this time. Red Hat invites you to ask your support representative to propose this request, if appropriate and relevant, in the next release of Red Hat Enterprise Linux. If you would like it considered as an exception in the current release, please ask your support representative. Reply at: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/304393/comments/92 ------------------------------------------------------------------------ On 2011-12-08T15:44:58+00:00 bugzilla wrote: (In reply to comment #91) > Red Hat Enterprise Linux 6.0 is now available and should resolve > the problem described in this bug report. It won't since there is no portrelease support in the 6.x ypbind scripts. Reply at: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/304393/comments/93 ------------------------------------------------------------------------ On 2011-12-08T15:48:17+00:00 orion wrote: It's not ypbind that needs to use portreserve/release, it's everything else that uses ports in the rpc port range. Reply at: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/304393/comments/94 ------------------------------------------------------------------------ On 2011-12-08T15:58:28+00:00 jeremy wrote: Dovecot is missing support portreserve/release (at least in Scientific Linux 6.1). Reply at: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/304393/comments/95 ------------------------------------------------------------------------ On 2011-12-08T17:57:51+00:00 bugzilla wrote: (In reply to comment #103) > It's not ypbind that needs to use portreserve/release, it's everything else > that uses ports in the rpc port range. What I discovered via portreserve(1) and testing is that when portreserve starts, it listens on all the reserved ports that have been configured. Just before the real daemon starts, it needs to run portrelease so the *real* daemon can listen on it. Look at: grep portrelease /etc/init.d/* cat /etc/portreserve/cups In the case of ypbind, which can listen either on a random port (unfixable) or a fixed port (via setting OTHER_YPBIND_OPTS). I hard- code to port 900 by setting /etc/sysconfig/network:OTHER_YPBIND_OPTS="-p 900" To fix ypbind, I see two potential ways - (1) it's init script needs to parse out the -p parameter and if you get something, call portrelease on that port. Something like: ypport=`echo $OTHER_YPBIND_OPTS | sed 's/.*-p[[:space:]]*\(\<.*\>\).*/\1/'` [ -n "$ypport" -a -x /sbin/portrelease ] && /sbin/portrelease $ypport &>/dev/null || : Or (2), since the user needs to reserve a port by dropping a file into /etc/portreserve/ anyway, force them to use the service named 'ypbind' and just portrelease that: [ -x /sbin/portrelease ] && /sbin/portrelease ypbind &>/dev/null || : Hopefully I'll get time to test this today. Should I open a new bug on RHEL6 for this issue? I searched and could not find one... Reply at: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/304393/comments/96 ------------------------------------------------------------------------ On 2012-01-31T11:34:18+00:00 ksrot wrote: I have changed the component to "distribution". Please file a new bug for each affected component and use this one as a tracker. rsync bug filed as Bug 786076. Reply at: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/304393/comments/97 ------------------------------------------------------------------------ On 2012-05-03T19:33:21+00:00 dyocum wrote: This bug exists in RHELv5.x, too. I noticed it when trying to use heartbeat (port 694). Can we get portreserve backported to RHELv5.x? Reply at: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/304393/comments/98 ------------------------------------------------------------------------ On 2012-06-27T08:49:16+00:00 ovasik wrote: Just having portreserve in RHEL-5.X will not solve the issue, you need to update all the packages which already use it in RHEL-6 to achieve same results. And this is IMHO very unlikely. Reply at: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/304393/comments/100 ------------------------------------------------------------------------ On 2012-06-27T17:00:38+00:00 dyocum wrote: I wasn't suggesting updating all the RHEL5 packages that would need portreserve, but having the package itself as part of the distro (instead of having to go to some third party repo, which is what I ended up doing) would go a long way to allow a sysadmin solve the problem, IMO. Even if it made it into EPEL for RHEL5 I think I'd be happy... Reply at: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/304393/comments/101 ------------------------------------------------------------------------ On 2012-10-23T20:44:00+00:00 hamiller wrote: I attached this bug to case 00721174, as the new RHS product can (and will) assign a port for every storage brick. In huge systems we have seen this consume all available ports under 1024. Reply at: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/304393/comments/102 ------------------------------------------------------------------------ On 2014-04-27T12:48:49+00:00 ejtr wrote: Having just been caught out by this bug in CentOS6 with heartbeat, ( UDP Port 694 ), and looking at the AFS /IPMI Port 623/664 bug mentioned in previous comments, it doesn't seem unreasonable to me to make portmap/rpcbind honour sunrpc.min_resvport/sunrpc.max_resvport as per comment 86. I presume rpc.mountd honours these proc settings, and the original setting of 600 minimum was modified specifically so as to avoid IPMI hardware clashes. If that's the case, then it would seem rpcbind is STILL vulnerable to a potential clash with IPMI hardware as long as a suitably configured portreserve is not running, even if no actual "real" daemons use those ports. Since there's willingness to avoid NFS mounts clashing, why not "protect" rpcbind with the same tweak? If this were done, then sysadmins who only have a few clashing services in the 6xx range, but only a modicum of simultaneous RPC services/ports, could avoid the whole mess by simply raising sunrpc.min_resvport to 700, for instance. In more complex cases, I admit that it might well be necessary to employ portreserve, but the /proc setting might well be sufficient in many cases. Reply at: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/304393/comments/103 ------------------------------------------------------------------------ On 2015-02-04T16:01:08+00:00 lhecking wrote: I would just like to add that I have this problem on CentOS6 with ypserv *every* time I reboot a particular server - 6.0 through 6.6. And occasionally on CentOS 5.11 with ypbind/cups. Reply at: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/304393/comments/104 ------------------------------------------------------------------------ On 2015-03-16T22:42:07+00:00 erco wrote: I haven't seen this solution mentioned in this thread: /proc/sys/net/ipv4/ip_local_reserved_ports Supposedly port numbers added to this file will be skipped over by the glibc functions that auto-assign reserved ports as used by tools like nfs/nis/etc. Some interesting details here: http://www.mjmwired.net/kernel/Documentation/networking/ip-sysctl.txt#716 https://lkml.org/lkml/2012/3/10/187 Reply at: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/304393/comments/105 ------------------------------------------------------------------------ On 2016-03-08T19:54:37+00:00 areichow wrote: Any chance we'll see a fix? Having this issue on RHEL 6.7 with rpc.statd. No port collisions, but in our environment we are required to have specific ports/port ranges defined for a particular service. There doesn't seem to be anyway to force rpc.statd to use a particular port rather than follow the pid % 424 + 600 formula. Reply at: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/304393/comments/107 ------------------------------------------------------------------------ On 2018-07-24T15:57:08+00:00 rkudyba wrote: Seeing this with Dovecot on Fedora 28: Jul 24 11:12:24 ourdomain dovecot[1838]: Error: service(imap-login): listen(::, 993) failed: Address already in use Jul 24 11:12:24 ourdomain dovecot[1838]: master: Error: service(pop3-login): listen(*, 995) failed: Address already in use Jul 24 11:12:24 ourdomain dovecot[1838]: master: Error: service(pop3-login): listen(::, 995) failed: Address already in use Jul 24 11:12:24 ourdomain dovecot[1838]: Fatal: Failed to start listeners Jul 24 11:12:24 ourdomain dovecot[1838]: master: Error: service(imap-login): listen(*, 993) failed: Address already in use Jul 24 11:12:24 ourdomain dovecot[1838]: master: Error: service(imap-login): listen(::, 993) failed: Address already in use Jul 24 11:12:24 ourdomain dovecot[1838]: master: Fatal: Failed to start listeners Jul 24 11:12:24 ourdomain systemd[1]: dovecot.service: Control process exited, code=exited status=89 Jul 24 11:12:24 ourdomain systemd[1]: dovecot.service: Failed with result 'exit-code'. Jul 24 11:12:24 ourdomain systemd[1]: Failed to start Dovecot IMAP/POP3 email server. netstat -lnp | grep 993 unix 2 [ ACC ] STREAM LISTENING 39993 1075/httpd /run/httpd/cgisock.972 Reply at: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/304393/comments/108 ------------------------------------------------------------------------ On 2018-07-24T15:59:42+00:00 fweimer wrote: (In reply to RobbieTheK from comment #137) > Seeing this with Dovecot on Fedora 28: > Jul 24 11:12:24 ourdomain dovecot[1838]: Error: service(imap-login): > listen(::, 993) failed: Address already in use > netstat -lnp | grep 993 > unix 2 [ ACC ] STREAM LISTENING 39993 1075/httpd > /run/httpd/cgisock.972 That is something else, the grep doesn't show a TCP socket on port 993. Reply at: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/304393/comments/109 ------------------------------------------------------------------------ On 2018-11-08T16:40:11+00:00 rkudyba wrote: This is still happening after a reboot, Fedora 28, Nov 8 12:21:41 kopernik dovecot[1386]: Error: service(pop3-login): listen(*, 995) failed: Address already in use Nov 8 12:21:41 kopernik dovecot[1386]: Error: service(pop3-login): listen(::, 995) failed: Address already in use Nov 8 12:21:41 kopernik dovecot[1386]: Error: service(imap-login): listen(*, 993) failed: Address already in use Nov 8 12:21:41 kopernik dovecot[1386]: Error: service(imap-login): listen(::, 993) failed: Address already in use After restarting dovecot it works: netstat -lnp | grep 993 tcp 0 0 0.0.0.0:993 0.0.0.0:* LISTEN 4622/dovecot tcp6 0 0 :::993 :::* LISTEN 4622/dovecot Reply at: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/304393/comments/110 ** Bug watch added: Sourceware.org Bugzilla #1014 https://sourceware.org/bugzilla/show_bug.cgi?id=1014 ** Bug watch added: Novell/SUSE Bugzilla #262341 https://bugzilla.novell.com/show_bug.cgi?id=262341 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to cups in Ubuntu. https://bugs.launchpad.net/bugs/304393 Title: rpcbind grabs ports used by other daemons such as cupsd Status in cups package in Ubuntu: Confirmed Status in rpcbind package in Ubuntu: New Status in Fedora: Confirmed Bug description: Binary package hint: cups cups 1.3.9-2ubuntu4 From /var/log/cups/error_log: cups: unable to bind socket for address 127.0.0.1:631 - Address already in use. Nothing actually looks wrong. 127.0.0.1:631 is only in use by cupsd when started. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/304393/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
