cups "bad request"

Nareto · 2014-02-09 14:58:49

Hello, a recent upgrade seems to have changed something in cups. I can't access anymore localhost:631, I get "Bad request". Here's my /etc/hosts:

127.0.0.1	localhost.localdomain	localhost triad
::1		localhost.localdomain	localhost

and for cupsd.conf I just moved the old one and used the cupsd.conf.pacnew, renaming it to cupsd.conf

from netstat it seems cups is only listening on ipv6:

$ netstat -ltunp |grep 631
(Not all processes could be identified, non-owned process info
 will not be shown, you would have to be root to see it all.)
tcp6       0      0 :::631                  :::*                    LISTEN      -

I don't know why, there's

Listen localhost:631

in cupds.conf. any help is very appreciated

jwhendy · 2014-02-09 15:27:53

Hmmm. That's odd. I saw you posted in the other similar thread, as I did. Unfortunately, my fix was quite simple, but I still don't understand why cups broke on me. All I had to do was change /etc/hosts from this:

127.0.0.1	localhost.localdomain	localhost archPad
#::1		localhost.localdomain	localhost archPad

to this:

127.0.0.1	localhost.localdomain	localhost archPad
::1 		localhost.localdomain	localhost archPad

Out of curiosity, does it work to add your computer's hostname to the ipv6 line? In other words, can you try:

127.0.0.1	localhost.localdomain	localhost triad
::1		localhost.localdomain	localhost triad

I have ipv6 disabled as I used to have goofy internet issues some 1-2 years ago and that was a suggested fix. I don't like enabling it, so if you come across why cups now requires it or how to enable it just for cups... I'd love to hear about it

myrlin · 2014-02-09 15:56:52

Same problem here.

It works OK if I start Firefox as root, then type "localhost:631"

Could it be some kind of permission problem?

jwhendy · 2014-02-09 16:07:27

@myrlin: sounds like it, but root shouldn't be required just to view localhost:631. I've never started with root, and prior to this could print, view jobs, print test pages, and cancel jobs without root access. I only got a uname/password popup when I needed to add/delete/modify a printer. I did make sure I was in the lp group, and for whatever reason I thought the wheel group might be relevant? Just scanning the wiki on cups the only other groups they mention are sys and creating one called lpadmin.

While those are possible routes, I'm more curious about why I had a perfectly working system and then it stopped being so.

cris9288 · 2014-02-09 16:11:55

Have you configured cups to allow you to access it through the administration page? What does your cupsd.conf look like?

jwhendy · 2014-02-09 16:17:17

Do any of the changelogs from the CUPS 1.71 release seem like candidates? It was released on 1/8/2014, which seems close to the right timeline. My libcups on my home computer (which I maybe update once ever 1-2 weeks) updated on 1/22.

jwhendy · 2014-02-09 16:25:03

@cris9288: should configuration (or lack thereof) prevent acess to localhost:631 at all? I get that it could affect access to admin tasks, but the OP's issue (and what mine was) involved no access at all.

I've never changed my /etc/cupsd.conf and never had an issue until very recently. Printing has always gone relatively well for me, and only last week did I start getting "Bad request" or 401's depending on if I did localhost:631 or 127.0.0.1:631.

jwhendy · 2014-02-09 16:58:15

Interesting. It's not about /etc/hosts, at least based on my home computer. I can access localhost:631 and still have the ipv6 version of my localhost commented out:

127.0.0.1	localhost.localdomain	localhost archPad
#::1		localhost.localdomain	localhost archPad

Here are my groups:

$ groups
lp wheel video audio optical storage power users

I have my work computer at home this weekend, so I'll see if I can figure out the difference between my two Arch setups and post back.

jwhendy · 2014-02-09 20:08:58

Aha! Found a difference, prompted by this Gentoo post. The post suggests adding the file /usr/lib/systemd/system/cups.socket:

[Unit] 
Description=CUPS Printing Service Sockets 

[Socket] 
ListenStream=/var/run/cups/cups.sock 

[Install] 
WantedBy=sockets.target

Checking, Arch already has that file, and I found three cups-related services running:

$ sudo systemctl list-units
# use /cups to search for cups in list of services
cups.path                                                                    loaded active waiting   CUPS Printer Service Spool
cups.service                                                                 loaded active running   CUPS Printing Service
cups.socket                                                                  loaded active running   CUPS Printing Service Sockets

This is on my work laptop where uncommenting my ipv6 line in /etc/hosts worked, so I checked on my home laptop where it's still commented out and yet I have access to localhost:631. cups.path and cups.socket were not running!

I simply ran the following on my work laptop, and now the cups web interface is fine again:

$ sudo systemctl stop cups.path
$ sudo systemctl stop cups.socket
$ sudo systemctl restart cups.service

It comes down to cups.socket; if I start cups.path and then cups.service, it still works. To flush out all the options, here's the behavior summary (in all cases, I stopped all three services, and then started them fresh). For combinations of cups.socket or cups.path, I started that first, then cups.service. In the case of all three, cups.socket has to come first, then cups.path, and finally cups.service:

| cups.path | cups.socket | cups.service | localhost:631           |
|-----------+-------------+--------------+-------------------------|
|         0 |           0 |            0 | unavailable (obviously) |
|         0 |           0 |            1 | works                   |
|         0 |           1 |            1 | bad request             |
|         1 |           0 |            1 | works                   |
|         1 |           1 |            1 | bad request             |

For a last attempt to track this down, if I comment out the ListenStream=631 line (just tried it since the Gentoo file example didn't have it), I can have all three running and still get to localhost:631:

# changed file to read as below, then stopped all three services and started them fresh
# start cups.socket, then cups.path, then cups.service

$ cat /usr/lib/systemd/system/cups.socket 
[Unit]
Description=CUPS Printing Service Sockets

[Socket]
ListenStream=/run/cups/cups.sock
#ListenStream=631

[Install]
WantedBy=sockets.target

So, it seems it's related to the extra ListenStream=631 line. To verify this in one last bit of sleuthing (I was still curious why this only recently started popping up on the Arch forums), I grabbed the ARM's copy of cups from 01/01/2014 (pre 1.7.1 release), untarred it, and looked at the contents.

$ cd /path/to/cups-1.7.0-2-x86_64.pkg.tar.xz
$ tar -xvf cups-1.7.0-2-x86_64.pkg.tar.xz
$ cat ./usr/lib/systemd/system/cups.socket

[Unit]
Description=CUPS Printing Service Sockets

[Socket]
ListenStream=/run/cups/cups.sock

[Install]
WantedBy=sockets.target

No ListenStream=631 line!

Is this a bug, an unintended consequence of the addition of that line (for whatever reason it was added), or something else?

Nareto · 2014-02-09 20:51:31

well jwhendy (fellow org-mode user I see ), what to say, you did it all!! I can confirm that that line is the culprit: commenting it works for me too. So I'd say it's indeed a bug? cheers, and thank you

jwhendy · 2014-02-09 21:22:06

@Nareto: did you figure that out just from the ascii table!?! Glad that worked. I'll go ahead and file a bug report. At least it'll get the attention of Arch developers who can provide input on whether or not this was the intended behavior and possible config modifications to allow everything to play nicely.

I'm still perplexed as to why you having an ipv6 localhost line wouldn't have taken care of it as on my system. Did you ever try adding `triad` to your ipv6 line in /etchosts (*with* the ListenStream=631 line still active)? I'll post back with the bug report link and update once it's resolved.

jwhendy · 2014-02-09 21:44:07

Glad I did a search first... turns out a bug report was already filed back on Jan 27! I added links to the cups-related threads like this there, along with a summary of my findings. @Nareto, you should definitely try to print something when you get a chance. One comment at the bug report is that commenting the ListenStream=631 line restored the web interface, but he couldn't print. I seem to be able to print with either the modified cups.socket file or both cups.path and cups.socket stopped and only cups.service running.

jwhendy · 2014-03-01 17:24:58

@Nareto: do you still have the line in cups.socket commented out? I've been posting a bit in this bug report and believe my issue is resolved, and I *don't* have that line commented out any longer. My issue was having not disabled ipv6 from the kernel line in my syslinux config and yet not having an ipv6 address in /etc/hosts.

I would have figured your setup should work from your first post, but I didn't see a response from you on whether or not you'd added "triad" to your ipv6 address and tried that. Can you give this a shot? You're the only user in the forum posts or bug reports I've seen not resolve the issue from simply making sure an ipv6 address was present in /etc/hosts. Thus, if you're willing:

- uncomment the ListenStream line in /usr/lib/systemd/system/cups.socket
- make sure you have an /etc/hosts like so:

127.0.0.1	localhost.localdomain	localhost triad
::1		localhost.localdomain	localhost triad

- setup cups so only socket and path are started:

# systemctl stop cups.service
# systemctl stop cups.path
# systemctl stop cups.socket
# systemctl disable cups.service
# systemctl enable cups.socket
# systemctl enable cups.path

- make sure you don' t have 'ipv6.disable=1' in your bootloader kernel line

- reboot and visit localhost:631

Arch Linux

#1 2014-02-09 14:58:49

cups "bad request"

#2 2014-02-09 15:27:53

Re: cups "bad request"

#3 2014-02-09 15:56:52

Re: cups "bad request"

#4 2014-02-09 16:07:27

Re: cups "bad request"

#5 2014-02-09 16:11:55

Re: cups "bad request"

#6 2014-02-09 16:17:17

Re: cups "bad request"

#7 2014-02-09 16:25:03

Re: cups "bad request"

#8 2014-02-09 16:58:15

Re: cups "bad request"

#9 2014-02-09 20:08:58

Re: cups "bad request"

#10 2014-02-09 20:51:31

Re: cups "bad request"

#11 2014-02-09 21:22:06

Re: cups "bad request"

#12 2014-02-09 21:44:07

Re: cups "bad request"

#13 2014-03-01 17:24:58

Re: cups "bad request"

Board footer