Arch Linux

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#44521 - [cups] Using hostname in /etc/cups/cupsd.conf Listen directive makes cupsd listen on the wrong IP

Attached to Project: Arch Linux
Opened by Bogdan Szczurek (thebodzio) - Friday, 10 April 2015, 00:46 GMT
Last edited by Andreas Radke (AndyRTR) - Wednesday, 15 April 2015, 15:06 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Andreas Radke (AndyRTR)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No



When cupsd is instructed in /etc/cups/cupsd.conf to listen only on some selected interfaces (IPs), instead on all (by “Port” directive), it may happen, that the daemon ends up listening on the wrong IP, if “Listen” directive was supplied with hostname (instead of explicit IP address) and cupsd wasn't able to query DNS to supply proper IP for the hostname. It's most likely to happen, when the host running cupsd relies on DHCP to configure its interfaces and cupsd is started before relevant interfaces are brought up.

For example:

I'm booting my host. In /etc/cups/cupsd.conf (original attached to this report) I've got 3 “Listen” directives: one set to localhost, one to socket and one to my hostname (“gizmo:631”). When the host is up and running, I can see (ss -tuln | grep -i 631) that cupsd listens on localhost ( and on, instead on the IP assigned to my host via DHCP. Restarting cupsd service (I'm using systemd), of course, solves the problem, but it's at least inconvenient to do.

Obviously setting IP to some explicit value would be, most of the time, a feasible option, but that kind of hard-coding things may be dangerous too.

Maybe dependency on network would be in order in cupsd service?

Additional info:
* any

Steps to reproduce:
* Make sure cupsd listens only on interfaces defined by “Listen” directives in /etc/cups/cupsd.conf and at least one of these interfaces is defined as a hostname.
* Make sure that previously given hostname's IP can be retrieved by DNS query.
* Make sure org.cups.cupsd.service is enabled and appropriate interface is configured by DHCP.
* Boot the system.
* Check the IPs of the interfaces the cups daemon listens on.
This task depends upon

Closed by  Andreas Radke (AndyRTR)
Wednesday, 15 April 2015, 15:06 GMT
Reason for closing:  Won't fix
Comment by Andreas Radke (AndyRTR) - Friday, 10 April 2015, 04:26 GMT
We are using upstream .service files. If you think there's a bug please file this there:
Comment by Bogdan Szczurek (thebodzio) - Friday, 10 April 2015, 11:32 GMT
Thank you! I will!
Comment by Bogdan Szczurek (thebodzio) - Friday, 10 April 2015, 22:03 GMT
Bug report filed to cups:
Comment by Bogdan Szczurek (thebodzio) - Wednesday, 15 April 2015, 14:50 GMT
It appears that using “hostname” in “Listen” directive in the case of dynamically configured network interface, is most non-standard thing to do. Also, it seems that it is as rare, that I was about the first user to report any problems with it.

Anyway, the proper way to do things in this case is:

a) hardcode hostname to IP assignment in /etc/hosts and then use “Listen hostname”,
b) use the IP explicitly,
c) just use “Port 631” or “Listen *:631” and rely on cups' ACLs and/or firewall rules to narrow down the access rights.

As for me, I'll take a look at Arch's Wiki and add info about that if necessary.

Bottom line is: I think it can be safely marked as “WONTFIX”.