Description of problem: - Impossible to print or to do anything in the "Printing Configuration" interface of MCC. - In the MCC screen "Manage System Services", CUPS is displayed as stopped, even when the checkbox "When starting" is selected, and it does want to start manually by clicking the button "Start". Version-Release number of selected component (if applicable): - Cauldron, last update. How reproducible: - Open Cauldron and try to print or to configure a printer. - Everything is OK again when launching CUPS by hand.
Alors, we must find out why. But first - is this a problem that has just appeared? Since the last CUPS update, or more recent updates? To see what version of cups you have, and when it was last updated (my system): $ LANG=C rpm -q --last cups cups-2.3.3op1-1.mga8.x86_64 Wed Dec 9 21:01:45 2020 If you know when the problem started, and it is *not* the same as the last CUPS update, the following command lists all system updates in reverse date order, so you can see (and paste, if necessary) the updates done at any one time; for example only the updates done just before you first experienced the problem: $ rpm -qa --last | less in case anything else might be the cause. > Impossible to ... do anything in the "Printing Configuration" > interface of MCC. This one? MCC-Hardware-Configure Printing [& scanning]-Install Printer [which is the same as Tools-System Tools-Print Settings] What happens? Does it show your installed printer(s)? Does the Server-Connect menu item show anything? From your description, it looks as if the CUPS service *is* ticked to start (in MCC), but does not; but does start if you click 'start' [now]. Can you please confirm that this is the correct interpretation ("it does want to start manually" is a bit flou). ------------------------------- In my own up-to-date Cauldron/Mageia 8 system, without ever having fiddled with it, the 'cups' service is shown in MCC-System-Manage Services as 'running' and ticked 'to start' [at startup]. 'cups-browsed' & 'cups-lpd.socket' are both stopped, and not to start. # systemctl status cups shows ● cups.service - CUPS Scheduler Loaded: loaded (/usr/lib/systemd/system/cups.service; enabled; vendor pres> Drop-In: /usr/lib/systemd/system/cups.service.d └─server.conf Active: active (running) since Tue 2020-12-22 19:49:05 CET; 1h 16min ago TriggeredBy: ● cups.socket ● cups.path Docs: man:cupsd(8) Main PID: 1279 (cupsd) Status: "Scheduler is running..." Tasks: 2 (limit: 4356) Memory: 3.9M CPU: 104ms CGroup: /system.slice/cups.service └─1279 /usr/sbin/cupsd -l Rha 22 19:49:03 localhost.localdomain systemd[1]: Starting CUPS Scheduler... Rha 22 19:49:04 localhost.localdomain cupsd[1279]: Missing value on line 59 of /var/cache/cups/job.cache Rha 22 19:49:05 localhost.localdomain systemd[1]: Started CUPS Scheduler. --- When you know that your CUPs service is not running, please do the same command and post the output. Also: $ journalctl -b --no-hostname | grep cupsd Rha 22 19:49:04 cupsd[1279]: Missing value on line 59 of /var/cache/cups/job.cache. Rha 22 19:49:04 dbus-daemon[691]: [system] Activating via systemd: service name='org.freedesktop.ColorManager' unit='colord.service' requested by ':1.27' (uid=0 pid=1279 comm="/usr/sbin/cupsd -l") Rha 22 20:44:08 msec[9513]: tcp 0 0 0.0.0.0:ipp 0.0.0.0:* LISTEN cupsd Rha 22 20:44:08 msec[9514]: tcp6 0 0 [::]:ipp [::]:* LISTEN cupsd So please do that as well, and post its output.
CC: (none) => lewyssmithSource RPM: ? => cups-2.3.3op1-1.mga8.src.rpm
I suspect this is bug 24189 - the workaround was only applied to Mageia 7. Check the journal to see if it is the same - multiple attempts to start cups, ending in failure.
CC: (none) => mageia
> Is this a problem that has just appeared? Since the last CUPS update, or more > recent updates? I cannot say exactly when the problem occured, because on my end Cauldron is running in a sandbox which I don't use daily for printing. But I'm sure it worked when I installed Cauldron the first time, and after a couple of updates. > To see what version of cups you have, and when it was last updated: [michel@localhost ~]$ LANG=C rpm -q --last cups cups-2.3.3op1-1.mga8.x86_64 Thu Dec 10 10:44:50 2020 > Impossible to ... do anything in the "Printing Configuration" > interface of MCC. > This one? MCC-Hardware-Configure Printing [& scanning]-Install Printer > [which is the same as Tools-System Tools-Print Settings] Yes > What happens? Does it show your installed printer(s)? Nothing? The windows is empty with just an information message (see attachment #1 [details]). > Does the Server-Connect menu item show anything? Then you get an error message (see attachment #2 [details]) > From your description, it looks as if the CUPS service *is* ticked to start > (in MCC), but does not; but does start if you click 'start' [now]. Can you > please confirm that this is the correct interpretation ("it does want to start > manually" is a bit flou). Yes, the ckeckbox is ticket to start, but NO, it *does not* want to start when you mouseclick the button "Start now". ------------------------------- > In my own up-to-date Cauldron/Mageia 8 system, without ever having fiddled > with it, the 'cups' service is shown in MCC-System-Manage Services as > 'running' and ticked 'to start' [at startup]. > 'cups-browsed' & 'cups-lpd.socket' are both stopped, and not to start. Correct. Exactly the same on my end. # systemctl status cups [What you see] ● cups.service - CUPS Scheduler Loaded: loaded (/usr/lib/systemd/system/cups.service; enabled; vendor pres> Drop-In: /usr/lib/systemd/system/cups.service.d └─server.conf Active: active (running) since Tue 2020-12-22 19:49:05 CET; 1h 16min ago TriggeredBy: ● cups.socket ● cups.path Docs: man:cupsd(8) Main PID: 1279 (cupsd) Status: "Scheduler is running..." Tasks: 2 (limit: 4356) Memory: 3.9M CPU: 104ms CGroup: /system.slice/cups.service └─1279 /usr/sbin/cupsd -l Rha 22 19:49:03 localhost.localdomain systemd[1]: Starting CUPS Scheduler... Rha 22 19:49:04 localhost.localdomain cupsd[1279]: Missing value on line 59 of /var/cache/cups/job.cache Rha 22 19:49:05 localhost.localdomain systemd[1]: Started CUPS Scheduler. [What I get] ● cups.service - CUPS Scheduler Loaded: loaded (/usr/lib/systemd/system/cups.service; enabled; vendor preset: disabled) Drop-In: /usr/lib/systemd/system/cups.service.d └─server.conf Active: inactive (dead) TriggeredBy: ● cups.socket ● cups.path Docs: man:cupsd(8) déc. 23 10:47:52 localhost systemd[1]: Dependency failed for CUPS Scheduler. déc. 23 10:47:52 localhost systemd[1]: cups.service: Job cups.service/start failed with result 'dependency'. --- Also: $ journalctl -b --no-hostname | grep cupsd [What you see] Rha 22 19:49:04 cupsd[1279]: Missing value on line 59 of /var/cache/cups/job.cache. Rha 22 19:49:04 dbus-daemon[691]: [system] Activating via systemd: service name='org.freedesktop.ColorManager' unit='colord.service' requested by ':1.27' (uid=0 pid=1279 comm="/usr/sbin/cupsd -l") Rha 22 20:44:08 msec[9513]: tcp 0 0 0.0.0.0:ipp 0.0.0.0:* LISTEN cupsd Rha 22 20:44:08 msec[9514]: tcp6 0 0 [::]:ipp [::]:* LISTEN cupsd [What I get] déc. 23 10:47:51 udev-configure-printer[1241]: Docs: man:cupsd(8) déc. 23 10:47:52 udev-configure-printer[1302]: Docs: man:cupsd(8) déc. 23 10:47:52 udev-configure-printer[1306]: Docs: man:cupsd(8) déc. 23 10:47:52 udev-configure-printer[1310]: Docs: man:cupsd(8) déc. 23 10:47:52 udev-configure-printer[1314]: Docs: man:cupsd(8)
Created attachment 12145 [details] Attachment #1 [details]
Created attachment 12146 [details] Attachment #2 [details]
Hi, cups works great on my system: Operating System: Mageia 8 KDE Plasma Version: 5.20.4 KDE Frameworks Version: 5.76.0 Qt Version: 5.15.2 Kernel Version: 5.10.2-desktop-1.mga8 OS Type: 64-bit Processors: 4 × Intel® Core™ i5-6600K CPU @ 3.50GHz Memory: 15.6 Gio of RAM Graphics Processor: GeForce GTX 1660 Ti/PCIe/SSE2 / is on a nvme SSD. $ urpmq -i cups cups-2.3.3op1-1.mga8.src.rpm $ rpm -qa | grep cups cups-filesystem-2.3.3op1-1.mga8 cups-2.3.3op1-1.mga8 cups-drivers-foo2zjs-0.0-1.20121012.12.mga8 lib64cups-filters1-1.28.6-1.mga8 python3-cups-2.0.1-1.mga8 cups-common-2.3.3op1-1.mga8 lib64cups2-2.3.3op1-1.mga8 gutenprint-cups-5.3.3-4.mga8 cups-pk-helper-0.2.6-4.mga8 cups-filters-1.28.6-1.mga8 $ rpm -qa | grep system-config-printer system-config-printer-udev-1.5.13-1.mga8 system-config-printer-1.5.13-1.mga8 system-config-printer-libs-1.5.13-1.mga8 $ systemctl status cups.service ● cups.service - CUPS Scheduler Loaded: loaded (/usr/lib/systemd/system/cups.service; enabled; vendor preset: disabled) Drop-In: /usr/lib/systemd/system/cups.service.d └─server.conf Active: active (running) since Wed 2020-12-23 14:38:44 CET; 1min 49s ago TriggeredBy: ● cups.socket ● cups.path Docs: man:cupsd(8) Main PID: 58033 (cupsd) Status: "Scheduler is running..." Tasks: 3 (limit: 19129) Memory: 3.0M CPU: 14ms CGroup: /system.slice/cups.service ├─58033 /usr/sbin/cupsd -l └─58036 /usr/lib/cups/notifier/dbus dbus:// déc. 23 14:38:44 mageia.local systemd[1]: Starting CUPS Scheduler... déc. 23 14:38:44 mageia.local systemd[1]: Started CUPS Scheduler. Also, In a virtual machine, beta 2 Plasma x86_64 classic ISO MCC => Set printer... installs task-printing-server and task-printing-hp. This gives a cups.service and cups.socket to be enabled by default (see drakxservices) Even after a rebooted VM. Even after setting a printer. @Michel, can you attach here the /etc/cups/cupsd.conf file?
CC: (none) => ouaurelien
Status comment: (none) => no reproduced.
Created attachment 12147 [details] Attachment #3 [details] - cupsd.conf
> @Michel, can you attach here the /etc/cups/cupsd.conf file? See attachment #3 [details] -------------- Some more commands on my side : [root@localhost cups]# urpmq -i cups $MIRRORLIST: media/core/release/media_info/20201223-124855-info.xml.lzma Name : cups Version : 2.3.3op1 Release : 1.mga8 Group : System/Printing Size : 7648717 Architecture: x86_64 Source RPM : cups-2.3.3op1-1.mga8.src.rpm URL : http://www.cups.org Summary : CUPS printing system - Server package Description : CUPS printing system provides a portable printing layer for UNIX® operating systems. It has been developed by Apple Inc. to promote a standard printing solution for all UNIX vendors and users. CUPS provides the System V and Berkeley command-line interfaces. This is the main package needed for CUPS servers (machines where a printer is connected to or which host a queue for a network printer). It can also be used on CUPS clients so that they simply pick up broadcasted printer information from other CUPS servers and do not need to be assigned to a specific CUPS server by an /etc/cups/client.conf file. [root@localhost cups]# rpm -qa | grep cups cups-filters-1.28.6-1.mga8 cups-2.3.3op1-1.mga8 cups-pk-helper-0.2.6-4.mga8 cups-common-2.3.3op1-1.mga8 python3-cups-2.0.1-1.mga8 cups-filesystem-2.3.3op1-1.mga8 lib64cups-filters1-1.28.6-1.mga8 gutenprint-cups-5.3.3-4.mga8 lib64cups2-2.3.3op1-1.mga8 cups-drivers-foo2zjs-0.0-1.20121012.12.mga8 [root@localhost cups]# rpm -qa | grep system-config-printer system-config-printer-1.5.13-1.mga8 system-config-printer-libs-1.5.13-1.mga8 system-config-printer-udev-1.5.13-1.mga8
On Mageia 7 cups.service manages to work even though cups.path and cups.socket don't, but it's ugly. I think it's related to having /var as a separate partition. Michel, what do systemctl status cups.path and systemctl status cups.socket show you?
[michel@localhost ~]$ systemctl status cups.path ● cups.path - CUPS Scheduler Loaded: loaded (/usr/lib/systemd/system/cups.path; enabled; vendor preset:> Active: failed (Result: start-limit-hit) since Wed 2020-12-23 17:09:15 CET> Triggers: ● cups.service déc. 23 17:09:15 localhost systemd[1]: cups.path: Succeeded. déc. 23 17:09:15 localhost systemd[1]: Stopped CUPS Scheduler. déc. 23 17:09:15 localhost systemd[1]: Stopping CUPS Scheduler. déc. 23 17:09:15 localhost systemd[1]: Started CUPS Scheduler. déc. 23 17:09:15 localhost systemd[1]: cups.path: Succeeded. déc. 23 17:09:15 localhost systemd[1]: Stopped CUPS Scheduler. déc. 23 17:09:15 localhost systemd[1]: Stopping CUPS Scheduler. déc. 23 17:09:15 localhost systemd[1]: cups.path: Start request repeated too qu> déc. 23 17:09:15 localhost systemd[1]: cups.path: Failed with result 'start-lim> déc. 23 17:09:15 localhost systemd[1]: Failed to start CUPS Scheduler. lines 1-15/15 (END) ---------- [michel@localhost ~]$ systemctl status cups.socket ● cups.socket - CUPS Scheduler Loaded: loaded (/usr/lib/systemd/system/cups.socket; enabled; vendor prese> Active: failed (Result: start-limit-hit) since Wed 2020-12-23 17:09:15 CET> Triggers: ● cups.service Listen: /run/cups/cups.sock (Stream) déc. 23 17:09:15 localhost systemd[1]: cups.socket: Succeeded. déc. 23 17:09:15 localhost systemd[1]: Closed CUPS Scheduler. déc. 23 17:09:15 localhost systemd[1]: Stopping CUPS Scheduler. déc. 23 17:09:15 localhost systemd[1]: Listening on CUPS Scheduler. déc. 23 17:09:15 localhost systemd[1]: cups.socket: Succeeded. déc. 23 17:09:15 localhost systemd[1]: Closed CUPS Scheduler. déc. 23 17:09:15 localhost systemd[1]: Stopping CUPS Scheduler. déc. 23 17:09:15 localhost systemd[1]: cups.socket: Start request repeated too > déc. 23 17:09:15 localhost systemd[1]: cups.socket: Failed with result 'start-l> déc. 23 17:09:15 localhost systemd[1]: Failed to listen on CUPS Scheduler. lines 1-16/16 (END)
Thank you for all this extra information. (In reply to Martin Whitaker from comment #2) > I suspect this is bug 24189 - the workaround was only applied to Mageia 7. > Check the journal to see if it is the same - multiple attempts to start > cups, ending in failure. I wondered the same thing, but sought supporting evidence. Not sure that the journalctl O/P I suggested was the best. You (Michel) must look at that M7 bug to see whether you think it is the same: https://bugs.mageia.org/show_bug.cgi?id=24189#c51 https://bugs.mageia.org/show_bug.cgi?id=24189#c62 https://bugs.mageia.org/attachment.cgi?id=11443&action=diff https://bugs.mageia.org/show_bug.cgi?id=24189#c65 https://bugs.mageia.org/show_bug.cgi?id=24189#c73 https://bugs.mageia.org/show_bug.cgi?id=24189#c74 Two key points: * Is your printer already switched on when you start Mageia? If so, try switching it on afterwards. * Look at /usr/lib/systemd/system/cups.service and see whether it has the extra line that fixed the problem in M7. If not, add it and see.
i) I don't think this bug is the same as 24189 : the diagnostic messages aren't the same : ------------------------------------------ [root@localhost michel]# systemctl --failed UNIT LOAD ACTIVE SUB DESCRIPTION ● cups.path loaded failed failed CUPS Scheduler ● cups.socket loaded failed failed CUPS Sc heduler LOAD = Reflects whether the unit definition was properly loaded. ACTIVE = The high-level unit activation state, i.e. generalization of SUB. SUB = The low-level unit activation state, values depend on unit type. 2 loaded units listed. [root@localhost michel]# systemctl status cups ● cups.service - CUPS Scheduler Loaded: loaded (/usr/lib/systemd/system/cups.service; enabled; vendor pres> Drop-In: /usr/lib/systemd/system/cups.service.d └─server.conf Active: inactive (dead) TriggeredBy: ● cups.path ● cups.socket Docs: man:cupsd(8) déc. 29 10:03:44 localhost systemd[1]: Dependency failed for CUPS Scheduler. déc. 29 10:03:44 localhost systemd[1]: cups.service: Job cups.service/start fai> ------------------------------------------ ii) Yes ! The problem occurs only when the printer is already switched on when I launch Mageia. When the printer is off, cups is loaded and functional as expected. ------------------------------------------ iii) Adding the cup.services correction specified in 24189 ("StartLimitBurst=20") changes nothing in my case.
Thanks for feedback. To sum up, cupsd refuses to start at boot time when Printer (USB?) is plugged and turned ON. (In reply to Michel AUTEM from comment #12) > ii) Yes ! The problem occurs only when the printer is already switched on > when I launch Mageia. When the printer is off, cups is loaded and functional > as expected. > ------------------------------------------ > iii) Adding the cup.services correction specified in 24189 > ("StartLimitBurst=20") changes nothing in my case. So, my advice: After read this, reboot your computer with Printer (Mark, Model) connected and plugged ON. Do this command: $ su -c 'journalctl -b > ./bootlog_printer_ON.txt' Do the same with Printer Unplugged. $ su -c 'journalctl -b > ./bootlog_printer_OFF.txt' Please attach here. We do want where is culprit. cupsd should not the one. I suspect a UDEV bug per see comment #3.
Created attachment 12166 [details] bootlog_printer_ON.txt
Created attachment 12167 [details] bootlog_printer_OFF.txt
OK. Please find the two files attached hereafter.
Created attachment 12168 [details] relevant part of 12166 OK. 1) Booting + USB printer ON = CUPS fails to start. 2) Booting + USB printer OFF = CUPS starts well. 1) /var is mounted nearly 6 seconds before systemd starts cups. So, it is not /var dependent not a timing according to attachment 12166 [details] I really don't see any clue on what going on. Attached relevant lines from attachment 12166 [details]. This is an annoying bug that prevent a user to have a working out-of-the-box setup when he wants to turn on his computer. I don't own USB printer, but a networked one. I can't test on myself. But, now I really wonder what do you get if you, Michel, switch ON printer after complete system boot + user login. Can you print without needing to restart cups? In this situation, can you do same: $ su -c 'journalctl -f' and copy/paste output when switching ON your printer, to a txt file and please attach here.
Attachment 12167 is obsolete: 0 => 1 Attachment 12146 is obsolete: 0 => 1
I have a rarely used USB printer, which I normally turn on after booting; so I must remember to try booting with it already switched on.
Having switched my main desktop PC to cauldron, I can now reliably reproduce this bug. It does indeed have the same root cause as bug 24189, although due to other changes the messages in the log are not the same and the increased retry count needs to be applied in other places to have an effect. But that increased retry count wasn't a true fix - it just increased the chances of avoiding the issue. The root cause is in a patch that Mageia applies to udev-configure-printer. That program is automatically run by a udev rule when a printer is detected. The Mageia patch causes it to detect whether the cups service is running, and if not, tries to restart it. But the program is run via the configure-printer@ service, which has a dependency on cups.socket, which is part of the cups service group. The dependency rules mean that systemd terminates the configure-printer@ service before restarting the cups service group, but because the dependency is just on cups.socket, can restart the configure-printer@ service before cups.service has started, which allows it to go round the loop again. If the configure-printer@ service retries enough times, eventually it gets lucky and the cups service has started before it gets round to checking the status, and the loop is broken. The simplest fix seems to be to change the 'systemctl restart cups' in the Mageia patch to 'systemctl start cups'. But as the cups service is now socket/path driven, it's questionable whether that part of the patch is needed at all (or indeed, whether any part of that patch is still needed). Assigning to Thierry as the registered maintainer of the cups package.
Assignee: bugsquad => thierry.vignaudSummary: It's impossible to print without launching CUPS by hand. => The cups service fails to start on boot if a printer is already plugged in and powered onStatus comment: no reproduced. => (none)
I second Papoteur's admiration for your SimpleScan accents diagnostic, and here is another even more profound. Martin Sherlock Holmes looks good to me!
OK. You seem to progress, I do nothing on my end for now. Tell when you need some more testing. Happy new year to you all.
Just realised this is assigned to the wrong package/person. I'll take care of fixing it, as Nicolas is still busy with the Java stack...
Source RPM: cups-2.3.3op1-1.mga8.src.rpm => system-config-printer-1.5.13-1.mga8Assignee: thierry.vignaud => mageiaStatus: NEW => ASSIGNEDCC: (none) => mageia
Should be fixed with system-config-printer-udev-1.5.13-2.mga8
Resolution: (none) => FIXEDStatus: ASSIGNED => RESOLVED