cups-lpd: Unable to reserve port: Permission denied

Garry T. Williams gtwilliams at gmail.com
Sun Apr 1 19:11:28 UTC 2007


Recently I've noted that print jobs sent to my local network lp server
take over five minutes to actually be spooled to the print server.  I
ran strace on the running cups-lpd process and got this:

    rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
    rt_sigaction(SIGCHLD, NULL, {SIG_DFL}, 8) = 0
    rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
    nanosleep({1, 0}, {1, 0})               = 0
    geteuid32()                             = 0
    socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 4
    bind(4, {sa_family=AF_INET, sin_port=htons(981), sin_addr=inet_addr("0.0.0.0")}, 16) = -1 EACCES (Permission denied)
    close(4)                                = 0
    write(2, "ERROR: Unable to reserve port: P"..., 49) = 49
    rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
    rt_sigaction(SIGCHLD, NULL, {SIG_DFL}, 8) = 0
    rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
    nanosleep({1, 0}, {1, 0})               = 0
    geteuid32()                             = 0
    socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 4
    bind(4, {sa_family=AF_INET, sin_port=htons(980), sin_addr=inet_addr("0.0.0.0")}, 16) = -1 EACCES (Permission denied)
    close(4)                                = 0
    write(2, "ERROR: Unable to reserve port: P"..., 49) = 49

This repeats every second and the port for bind() decrements each
time.  Once the attempt is made on port 631, it succeeds and the print
job is spooled off to the remote server:

    socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 4
    bind(4, {sa_family=AF_INET, sin_port=htons(631), sin_addr=inet_addr("0.0.0.0")}, 16) = 0
    connect(4, {sa_family=AF_INET, sin_port=htons(515), sin_addr=inet_addr("192.168.0.1")}, 16) = 0

I checked the manual and it says:

    ERRORS
	   EACCES The address is protected, and the user is not the superuser.

Of course, the lpd process *is* running as root, so this makes no
sense to me.

I have no selinux avc messages indicating that selinux is responsible
for the EACCES errors.

I don't know where to go from here.

-- 
Garry T. Williams --- +1 678 656-4579




More information about the users mailing list