Arch Linux

I guess you can workaround the issue by disabling the cups.socket and just enabling the always on cups.service.

But can you please try to find out why that error happens? Check your systemd journal in what order services come up. I guess some required service isn't up at that time and we need to add some Requires or After directive to the socket service file.

Disabling the cups.socket works, the cups.service starts the socket much later. After numerous rounds of testing and rebooting I've found that the drive in fstab isn't related to the issue, I now can't seem to get the cups.socket to start during boot whether the external drive is attached or not. The problem comes from the new line in the cups.socket file.

ListenStream=631

If I remove that line and reboot, everything works. If the line is added I am unable to access my printers. However, despite not being able to access my printers there are no errors in the journal and the service shows as active. If I stop all the cups related services and restart them everything works.
It does appear to be related to another service which isn't available when it starts. I'll keep plugging away at it, just wanted to remove the red herring about the fstab.

thanks for a workaround, however printing still not working for me, only web access restored

Several other threads have appeared on the Arch forums related to this:
- https://bbs.archlinux.org/viewtopic.php?id=176201
- https://bbs.archlinux.org/viewtopic.php?id=157482
- https://bbs.archlinux.org/viewtopic.php?id=176930

I wish I'd found this sooner, as I sleuthed around for quite a long time to track down the same issue, the ListenStream=631 line in cups.socket. On one computer, I can verify that uncommenting my ipv6 address in /etc/hosts resolved the issue, however I was perplexed that I still had web interface access on localhost:631 with another Arch system even with that line commented out. I checked systemctl list-units and cups.path and cups.socket were not running on that system.

Stopping cups.service and starting cups.socket, cups.path, and cups.service (in that order) replicated the same "Bad Request" issue when trying to visit localhost:631 from both Chromium and Firefox.

I just set up my home printer and used Maintenance -> Print test page successfully with the two scenarios I've found that allow web interface access:
- cups.socket, cups.path, and cups.service (with modified #ListenStream=631 line)
- cups.socket and cups.path stopped and only cups.service running

Technically, I guess there are three scenarios; the third is with cups.path and cups.service, but I didn't try that.

I confirm that the ListenStream=631 line was added with 1.7.1. I grabbed the 01/01/2014 package (v1.7.0) from ARM, untarred it, and the systemd service doesn't have the line.

More digging. I searched around for more information on the "ListenStream=631" line and turned up a bug report that initiated the change on Arch:
- https://bugs.archlinux.org/task/32923

It appears it's purpose is such that cups.socket and cups.path can be started and *not* cups.service upon system boot. When one accesses localhost:631, cups.socket triggers cups.service to start, in order to keep it from constantly running. I'm still not *exactly* sure why that line causes issues with everyone, but I believe I've made more progress.

The systemd documentation mentions a line BindIPv6Only=option, which determines which protocol the ListenStream=port option will function with. The default is to use the system settings, found in /proc/sys/net/ipv6/bindv6only. It says the default for that is 'both', however mine ouputs '0' with cat, so I'm not sure what that means.

In any case, if I add 'BindIPv6Only=both' to cups.socket, I can access localhost:631 even with my ipv6 address commented in /etc/hosts.

In addition, I can confirm that starting only cups.socket and cups.path, followed by visiting localhost:631 starts cups.service, so this option appears to let everyone have what they want.

I've ipv6 enabled with assigned non-local address, but got this issue

With kernel parameter ipv6.disable=1 all issues should be gone right? Then someone should add this to the cups wiki page. Anything else to do?
You may want to keep an eye on the Debian systemd patch that currently sees some changes.

Can we close this one as fixed and  FS#32923  +  FS#38803  ?

> With kernel parameter ipv6.disable=1 all issues should be gone right?

Noone required ipv6? Are you guys using msdos?

@Andreas: I think this one, too (which I re-opened, unfortunately, but no longer have issues): https://bugs.archlinux.org/task/32923

I've been posting a lot in the forums and following these, and could take a shot at the Wiki. The Arch Cups setup will work in two scenarios (from my experience):
- ipv6 enabled, and an ipv6 address in /etc/hosts
- Using ipv6.disable=1 *and* having the ipv6 address commented out in /etc/hosts

In either of those scenarios, having cups.socket and cups.path started and visiting localhost:631 will start cups.service successfully. My confusion was *not* having disabled ipv6 via the kernel line and yet having my ipv6 address commented out.

This forum post is the only instance I've seen where someone appears to have an ipv6 address in /etc/hosts and yet still get the "Bad Request" error:
- https://bbs.archlinux.org/viewtopic.php?pid=1387476#p1387476

I just posted requesting an attempt to ensure that the hostname is featured in /etc/hosts, as in the first post it was missing.

EDIT: In other words, yes, I think the bugs are resolved. Re. the ipv6 comment that came in while I was typing this... I haven't run into a need for ipv6 in ~4 years of using Arch.

> I haven't run into a need for ipv6 in ~4 years of using Arch.

You a lucky for this but not the only one ArchLinux user. I have an ipv6 assignments for the working purposes so I have to request do not disable ipv6 due to cups bugs

@dron78: what's broken with cups when using a full working ipv6 setup? Gentoo adds BindIPv6Only=ipv6-only to the socket file:
http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/net-print/cups/files/cups-1.5.0-systemd-socket-2.patch?revision=1.2&view=markup

but Debian seems to drop this:
cups (1.7.1-6) unstable; urgency=low
.
* Add systemd socket activation support (Closes: #732435):
- Add Gentoo patch to enable runtime-detected systemd socket activation
cups (1.7.1-7) unstable; urgency=low
.
* systemd socket activation:
- Drop ListenDatagram from cups.socket as that's now in use by
cups-browsed
- Drop the Debian-specific patch to make sure that the localhost web
access works; Listen on 0.0.0.0 and [::] in the main patch instead

In my case with "white" inet6 address, cups web access denided and no printing works in this case

removing
ListenStream=631
helps and everything became work very well

the kernel ipv6.disable=1 parameter is not a good solution for me, since it's requred
and BindIPv6Only seems will break access from ipv6 address

I'm not really sure where the real bug is, but probably cups people should be more carefully looks to support systemd properly

Maybe someone already has access to their bugtracker - this is where FC "Don't enable IP-based systemd socket activation by default (bug #842365)"

http://pkgs.fedoraproject.org/cgit/cups.git/commit/cups-systemd-socket.patch?id=6ef39188975c03f6132a98c8cad20ce80b3d95d9

for me it looks like a cups ipv6 problem
firefox with network.dns.disableIPv6=true results in "Bad Request" on http://localhost:631/
with ipv6 enabled
http://127.0.0.1:631/ results in Forbidden
http://localhost:631/ works fine

Please check 1.7.1-4 in testing. I've added BindIPv6Only=ipv6-only to the socket file.

This is required in my IPv4 only setup to get a proper link shown in cups web interface when you want to modify a printer
and require to switch to the https admin interface address. Before there was a mix shown of IPv6+IPv4 and now the desired IPv4 only address will be shown.

This is now the same socket file that is used in Gentoo. Please some IPv4 + IPv6 user test it.

OK, I cheked and found a more bugs in cups ;)
http://localhost6:631 does not working

However for now BindIPv6Only it's a good solution for me if the ListenStream is really requred

ok. the initial bug seems fixed. if there's something wrong with a certain setup please a new issue.