Arch Linux

How do you want to know if cups is listening on port 631? That depends on the listen directive in cupsd.conf e.g.

Listen localhost:631

Because port 631 is the default. The package ships with it and any other distro (that I ever used) uses it too. I think that something like this should work out of the box for the default case, especially since basically every documentation that refers to the web interface uses port 631. And someone who changes the port would probably know enough to also change the systemd unit (which could be pointed out by a comment in both files).

Oh, I forgot that the default cups.socket unit comes with a "ListenStream=/var/run/cups/cups.sock", which is configurable by a Listen directive in cupsd.conf. So your main argument is actually void, imho ;)

+ListenStream=@CUPS_DEFAULT_DOMAINSOCKET@

This is what is in the cups-systemd-socket.patch. We use it the same way Fedora does.
http://pkgs.fedoraproject.org/cgit/cups.git/tree/cups-systemd-socket.patch

Suggestions welcome.

It should be safe to hardcode port 631 in the socket file since port 631 seems hardcoded in the documentation, also every tutorial and even our wiki tell the user to access the web interface at localhost:631. It doesn't make much sense (and is not obvious) to force the user to connect a printer (1) or open a print dialog before it is possible to access the web interface.

If a user changes the default port then the user is responsible for updating the socket file.

For Fedora things might automagically work if they ship something that tries to get the printers list when a DE starts, hence starting cupsd (just a guess). Or users might not have noticed that going to localhost:631 doesn't work if they use some other way to configure the printers.

(1) Connecting a physical printer triggers printer.target which starts cupsd and all is well.

I've been looking a bit more into this and if you want to add something more generic to the cups-systemd-socket.patch you can use:

+ListenStream=@CUPS_DEFAULT_DOMAINSOCKET@
+ListenStream=@DEFAULT_IPP_PORT@

This way if the default port is overridden with --with-ipp-port it will also get changed in the socket file.

I have noticed that if there are any (leftover?) spool files cupsd will also get started, this might hide the corner case not yet covered by the socket file.

I'm not for going an Arch specific way here. I'll stick with the Fedora way untill upstream would adopt service files (which I doubt - it's an Apple driven project and Debian - (Till K.) won't switch to systemd anytime soon as 2nd important project driving it forward).

Going to close this as "Won't implement" - But feel free to bring up generic systemd support to include in upstream project on the cups mailing list that I'm subscribed to.

what's wrong with mauro's solution? ...anyway, as systemd now got support for easy overriding of settings is unit files, i think using the default (631) port and keeping user responsible for any change is a good way to handle it (for 99.9% other users out there)...

I've implemented Mauros solution into cups 1.7.1-2 in testing repo. I'd prefer a solution where the socket.service file reads the variable at start from cupsd.conf file if possible.

Please tell me if you're happy with 1.7.1-2.

I'm not sure where to file this, but the fixing of this bug caused anyone with ipv6 disabled to have issues. I believe this bug fix may have also required the addition of "BindIPv6Only=both" to cups.socket per the system .socket docs. With ListenStream=631 alone, may forum posts are turning up with "Bad Request" errors when trying to access the cups web interface.

I plan to also post on this bug report again, but I'm also debating starting a new one as the description in that one confuses the issue with something related to fstab.
- https://bugs.archlinux.org/task/38684

Thanks for any input.
John

Seems to work fine for me with ipv6 enabled and disabled with ipv6.disable=1.

I've tried leaving only the socket enabled or everything (socket, path and service) and after rebooting cups was always working fine.

@MauroSantos: I'm not a very knowledgeable user when it comes to networking. Can you suggest some details I can go and grab from my system with the default Arch package settings so we can diagnose why this appears to be happening? Also, did you try with the ipv6 address line commented out in /etc/hosts? That seems to be the enabler for me with the default "ListenStream=631" line, though that hasn't fixed it for others (see the forum posts linked to in the bug report I linked to a couple posts up).

Yes I did comment the ipv6 address line in /etc/hosts. According to the wiki it can cause trouble if programs decide to use the ipv6 address, which is obviously not accessible, instead of the ipv4 address.

I might start by removing cups and any configuration files (after making backups), then remove any leftover spool files in /var/spool/cups, then reinstall cups and configure a printer. Using a new user account for setting up the new printer and testing might also be a good idea since it takes browser configuration cruft from the equation.

For checking what's listening where I would use 'ss' (owned by iproute2), it is better at listing what's listening on a socket (try 'ss -napt' as root). If things are still not working I suppose trying to look at cups' logs (and making them more verbose if possible) is an option that might provide clues as to why things are not working.

As a last resort I would fire up wireshark and would try to see what differs between an install that works and one that doesn't, it might provide clues about misconfiguration somewhere else.

@Mauro: Interesting re. the ipv6 line in /etc/hosts. Mine is directly attached to that. Thanks for the suggestions, and excellent idea re. a new user account. I'll try your suggestions and see if I can track it down to something specific. Hopefully I can try this out and post back with some logs/results this weekend.

Here's the results of testing some things so far, including the output of /var/log/cups/error_log and a couple variations on the `ss` command. Let me know if something else is of interest. I didn't replicate ipv6 issues on a new user yet... ran out of time and wanted to post where I got so far, which is that I can easily reproduce the problem on my system simply by commenting/uncommenting the ipv6 address in /ets/hosts **or** having it uncommented but adding `BindIPv6Only=both`to cups.socket. See the attached for the journal I kept of what I did.

I spot a problem at step 3 with "Simply commented out ipv6 line in /etc/hosts/ prior to rebooting". You are not disabling ipv6 and you ommit the information about how to reach localhost on ipv6. You can't (or shouldn't) have ipv6 enabled and not have the ipv6 localhost line in /etc/hosts.

I suppose the result is the same as not adding your hostname in /etc/hosts (1), some stuff will work fine and some other stuff will break in strange ways.

(1) As of now this is not exactly true, if you have "myhostname" in the hosts line of /etc/nsswitch.conf you don't need to add your hostname to /etc/hosts.

@Mauro: You may very well have solved the issue! I had no idea your observation would be a problem. I added `ipv6.disable=1` to my syslinux.cfg kernel line, still have my ipv6 address commented out in /etc/hosts, and am using the default cups.socket file (no BindIPv6Only modification), and localhost:631 just worked successfully after a reboot. I may modify the Arch wiki to make it clear that the kernel line or sysctl.d config files are the only way to disable ipv6. Apparently I've been doing this incorrectly for quite a long time.

I'll continue trying out this setup (I want to copy back my cups configs, re-install my work printers, and test), and can confirm after a few days that I'm still not having any issues. I'll notify some individuals having trouble on the Arch forums as well. If some can confirm, I think this can be re-closed, as it was a setup issue. Many thanks for the help!

I'm not sure how to deal this and what should be our desired behavior. Fedora doesn't seem to enable socket only activation by default and doesn't add that ListenStream=631 line to the coups.socket file. I take Fedora and Lennard as "upstream" in this case.

See http://pkgs.fedoraproject.org/cgit/cups.git/tree/cups-systemd-socket.patch?id=7cb9904f3bd15b82c2aed04b8218197f822ed579

See also http://fedoraproject.org/wiki/Packaging:Systemd#Socket_activation
http://0pointer.de/blog/projects/socket-activation.html
http://0pointer.de/blog/projects/socket-activation2.html

Debian is just jumping into this socket activation here that should probably give the wanted behavior you've also requested to implement in Arch:
https://lists.debian.org/debian-printing/2014/02/msg00065.html

They add this to the socket file:
+[Socket]
+ListenStream=@CUPS_DEFAULT_DOMAINSOCKET@
+ListenStream=631
+ListenDatagram=0.0.0.0:631
+BindIPv6Only=ipv6-only

I guess the change in cups 1.7.1-2 only adding ListenStream=631 wasn't enough.

For me what we have now in arch fixes this bug. On my machine I can't find any case where cups does not start when it should, I have tested it with ipv6 enabled and disabled (with ipv6.disable=1)(I haven't tested with ipv6.disable_ipv6=1). It is possible that some users do not have other parts of the system configured correctly and that's causing problems.

To me, the patch from debian does not seem to add anything that would be required to make things work, they use the same "ListenStream=@CUPS_DEFAULT_DOMAINSOCKET@" as we do. They hardcode the cups port, which we don't, they listen on UDP, which cups doesn't seem to listen on after starting, and as far as I can understand, in a dual stack machine they listen only on ipv6, thus breaking things if some ipv4 only machine tries to reach cups (if I'm reading the documentation correctly). This last issue might be a problem only for people sharing printers over the network.

Regarding fedora, like I said above, they might not have encountered the corner case we did yet, their patch seems to be initial enablement of systemd in general and might lack some further tuning. From their wiki page, I get the sense that either that wiki page is not very up-to-date or that they haven't given socket activation a good go yet.

On the other hand, if socket files can also be extended using /etc/systemd/system/unit.d/ (I think this was not possible when this bug was submitted), you could use what upstream provides and let users add whatever else might be needed. After more distros have given socket activation a go, I guess this can be revised and more things added to the socket file if needed, this might not be the best solution but it sticks with arch's philosophy of staying close to upstream.