FS#68814 - cups.service fails to start with [cups] 2.3.3+121+g63ffc5cd7-1 and [cups] 1:2.3.3op1-1

Attached to Project: Arch Linux
Opened by Steven McFeely (smcfeely) - Wednesday, 02 December 2020, 04:18 GMT
Last edited by Andreas Radke (AndyRTR) - Tuesday, 08 December 2020, 20:09 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To No-one
Architecture All
Severity High
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No

Details

Description:

cups.service fails to start with all versions of CUPS after [cups] 2.3.3+106+ga72b0140e-1 (as of 2020-12-01 that would be, [cups] 2.3.3+121+g63ffc5cd7-1 and [cups] 1:2.3.3op1-1). I was last able to successfully print on 2020-20-11.

I have made no changes to cups, cupsd.conf is identical to cupsd.conf.default.

I have reinstalled CUPS, but cups.service still fails to start.

I have attached the relevant dmesg output, journalctl -xe output and systemctl status output. In addition, I have attached a coredump and backtrace in case they are helpful.

I have not seen any report of a bug like this upstream.

I do not know if this is an arch issue or an upstream issue, so let me know if this should be reported to https://github.com/OpenPrinting/cups or somewhere else.

Steps to reproduce:
Attempt to start cups.service after updating from [cups] 2.3.3+106+ga72b0140e-1. This includes booting the machine if cups.service has been enabled.
This task depends upon

Closed by  Andreas Radke (AndyRTR)
Tuesday, 08 December 2020, 20:09 GMT
Reason for closing:  None
Additional comments about closing:  probably a bad config file caused this
Comment by Andreas Radke (AndyRTR) - Wednesday, 02 December 2020, 06:16 GMT
Your system is ful up to date (-Syu'ed)?

Please post your cupsd.conf, there also enable dubug logging and post your cups error.log.
Please also check the upstream report in the comment I have put into the PKGBUILD. Maybe post your setup
https://github.com/archlinux/svntogit-packages/commit/50a035fb456b9a8d11a8f353dd4bdabaf19d2113#diff-3e341d2d9c67be01819b25b25d5e53ea3cdf3a38d28846cda85a195eb9b7203a

You may also try to start cupsd from command line to avoid a possible systemd error.
Comment by Steven McFeely (smcfeely) - Wednesday, 02 December 2020, 16:33 GMT
Hi Andreas,

Yes my system is fully up to date (-Syu'ed)

Comment by Steven McFeely (smcfeely) - Wednesday, 02 December 2020, 17:55 GMT
Here are the additional files and information (I accidentally hit add comment instead of attach).

I did not see anything obvious in the PKGBUILD file. My system does have both network.target and network-online.target loaded and active. So, if CUPS need either one of them, then they are both ready to use. Given there has not been an official new CUPS version since the release of 2.3.3 on 2020-04-24, could this be a git issue? Should we be updating cups to match the upstream git-master when they have not made and official new release (there are bound to be regressions after all)? Upstream seems to document all new versions at cups.org and there is nothing new listed.

For reference, my machine is a Lenovo ThinkPad X395 and my printer is a Brother MFC-J6910DW that is connected through the network.
CPU: Ryzen 3700U
RAM: 16 GB
SSD: 1 TB Samsung 970 Pro
WiFi: Intel Wireless-AC 9260
DE: KDE Plasma

The Brother printer is using the drivers found here:
https://aur.archlinux.org/packages/brother-mfc-j6910dw/
https://aur.archlinux.org/packages/brscan4/
https://aur.archlinux.org/packages/brscan-skey/


When attempting to enable cups' debug-logging I get the following:

[smcfeely@smcfeely-laptop ~]$ sudo cupsd
[sudo] password for smcfeely:
[smcfeely@smcfeely-laptop ~]$ sudo cupsctl --debug-logging
cupsctl: Unable to connect to server: Bad file descriptor
[smcfeely@smcfeely-laptop ~]$ systemctl status cups
● cups.service - CUPS Scheduler
Loaded: loaded (/usr/lib/systemd/system/cups.service; enabled; vendor preset: disabled)
Active: inactive (dead) (Result: core-dump) since Wed 2020-12-02 09:02:42 EST; 2h 56min ago
TriggeredBy: ● cups.path
● cups.socket
Docs: man:cupsd(8)
Main PID: 1466 (code=dumped, signal=SEGV)

Dec 02 09:02:42 smcfeely-laptop systemd[1]: cups.service: Scheduled restart job, restart counter is at 5.
Dec 02 09:02:42 smcfeely-laptop systemd[1]: Stopped CUPS Scheduler.
Dec 02 09:02:42 smcfeely-laptop systemd[1]: Dependency failed for CUPS Scheduler.
Dec 02 09:02:42 smcfeely-laptop systemd[1]: cups.service: Job cups.service/start failed with result 'dependency'.


After running sudo cupsd, I am still unable to connect to http://localhost:631/ and the KDE system settings still claims the print service is not available (bad file descriptor). Searching in htop, I do not see any command running with the text cups in its path or name running.

I noticed that cupsd.conf has
LogLevel warn

What should this be changed to to manually enable the debug-logging (debug, error, etc.) and would anything else need to be done? Would it even help at all given cupsctl fails? All documentation I have seen, insists on using cupsctl.

If there is some other form of logging you wish for me to enable, then I will need a bit more specificity.
Comment by Andreas Radke (AndyRTR) - Wednesday, 02 December 2020, 18:23 GMT
A bit of web search quickly shows misconfigured cupds.conf or client.conf files to be the reason in most cases.

Please read your error.log file. Your cupsd.conf was broken for a long time. It's not needed to post the old stuff here. Your client.conf may be broken and is missing here.
Change LogLevel from "warn" to "debug" or even "debug2" and restart the service. Look out in the error.log for the error msg.

There have been minor changes in this release fixing old bugs. It's an official release (of this fork) now.

From a quick look your printer is AirPrint capable. You should do a fresh setup using driverless printing that is strongly recommended. Or remove the old driver setup and reinstall the printer in the webinterface. This may fix also any bug in client.conf.
Comment by rainer (raneon) - Thursday, 03 December 2020, 17:35 GMT
I'm now as well affected by this issue on my systems. I don't have a manual cups config. I noticed that my cups.socket was not enabled anymore. Anyway even when started manually and enabled again, I was not able to open localhost:631 or KDE printer settings. I have a brother printer too.

After manually running on the terminal the command "cupsctl" my printer appeared in the KDE settings and I could open localhost:631. I'm not sure what's wrong with this update. For me it seems like I had to run once "cupsctl" and then cups continued to work.
Comment by Steven McFeely (smcfeely) - Friday, 04 December 2020, 02:49 GMT
I went back and checked the error_log file and it looks like those errors started when the cupsd.conf file format was changed. I likely ran a system update late at night, decided to deal with the pacnew file for cupsd.conf the next day, shutdown the laptop and then forgot all about the pacnew file. Regardless, I was able to continue printing without an issue (which is why I never noticed there was a problem). I did update the cupsd.conf file on 2020-11-20, which is why, other than when I was downgrading CUPS on 2020-12-1, that was the last day of the error message.

When I checked /etc/cups/ & ~/.cups I do not have client.conf or client.conf.default files. When reinstalling cups via pacman -S cups (and saying yes to the reinstall) these files were not created. I checked a Fedora 33 machine of a family member that has this printer install with everything working and he had blank client.conf and client.conf.default files. In addition, when I checked https://www.cups.org/doc/man-client.conf.html, it notes that the file is deprecated on macOS. Given that I did not have the file and it was not generated by the reinstall, I wonder if this file was also deprecated on Linux.

Does anyone know if we should have client.conf and client.conf.default files for CUPS on Arch Linux? I do not know if new installs would have these files either. Given that I am having problems, I cannot rule out the possibility that this is part of the problem.

I created a blank client.conf and client.conf.default with 644 permissions, root as owner and group cups. This matches what the functioning Fedora 33 install is using (the only difference is that the group was lp on the Fedora system, but the Fedora system also had lp as the group for cupsd.conf). This did not fix the issue, however the systemctl error message changed to the contents of the attached file 'CUPS systemctl status output with client conf.txt'.

I have also attached the CUPS error_log for LogLevel debug and debug2 both with and without client.conf & client.conf.default. I do not know if the presence of these two files will provide a meaningful difference in the log, but I figured it was better to include it than not. One thing I did notice is that the debug files were considerably shorter with client.conf & client.conf.default present on the system.

While the printer may be AirPrint compatible, from what I saw on the Archwiki, I need those manufacturer drivers anyway for the built in scanner to work.

I will attempt uninstalling the AUR drivers tomorrow, Friday, to see if that makes a difference.
Comment by Steven McFeely (smcfeely) - Friday, 04 December 2020, 02:51 GMT
Hi Rainer,

Unfortunately for me, when I run cupsctl, I always get the following error message:

cupsctl: Unable to connect to server: Bad file descriptor
Comment by Andreas Radke (AndyRTR) - Friday, 04 December 2020, 06:36 GMT
client.conf is indeed obsolete and shouldn't be present anymore.

Just to make sure: you both have adopted the new reverted service file naming?

Please backup your cupsd.conf and printer.conf and try with clean default settings again.
If it keeps failing to start please open a bug @ https://github.com/OpenPrinting/cups/issues .
Comment by Andreas Radke (AndyRTR) - Friday, 04 December 2020, 06:43 GMT
Maybe another one is hitting this issue: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=976361
Comment by Steven McFeely (smcfeely) - Tuesday, 08 December 2020, 03:34 GMT
There was nothing wrong with the cups.d file (it was identical to the default file). However, there is no printer.conf.default file. So, not knowing what a default file should look like, I just deleted the entire /etc/cups folder and ran pacman -S cups. This caused cups.service to function properly again! I have no idea if it was the printer.conf file or one of the other files.

Loading...