Bug 24189 - cups.service fails on boot - multiple attempts - have to manually start
Summary: cups.service fails on boot - multiple attempts - have to manually start
Status: RESOLVED FIXED
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: 7
Hardware: All Linux
Priority: High major
Target Milestone: ---
Assignee: José Jorge
QA Contact:
URL:
Whiteboard:
Keywords:
: 25164 25406 (view as bug list)
Depends on:
Blocks:
 
Reported: 2019-01-16 10:46 CET by Robert Fox
Modified: 2020-06-11 00:31 CEST (History)
18 users (show)

See Also:
Source RPM: cups-2.2.11-2.mga7.src.rpm
CVE:
Status comment:


Attachments
journalctl output on boot (3.84 KB, text/plain)
2019-03-28 18:47 CET, w unruh
Details
TJ's journal of failed cups start (18.45 KB, text/plain)
2019-03-30 00:25 CET, Thomas Andrews
Details
Filtered output from journal with cups debug enabled, cups started on 3rd attempt (34.84 KB, text/plain)
2019-04-13 13:05 CEST, Martin Whitaker
Details
Potential fix (378 bytes, patch)
2020-01-06 10:39 CET, Dan Fandrich
Details | Diff

Description Robert Fox 2019-01-16 10:46:40 CET
Description of problem:
During boot cycle on a Cauldron based machine - cups fails to start (tries multiple times) - then when I manually start it it works - but with an error in jobcache

[root@FoxMain rfox]# systemctl --failed 
  UNIT                           LOAD   ACTIVE SUB    DESCRIPTION                                
● cups.path                      loaded failed failed CUPS Scheduler                             
● cups-browsed.service           loaded failed failed Make remote CUPS printers available locally
● cups.service                   loaded failed failed CUPS Scheduler                             
● plymouth-start.service         loaded failed failed Show Plymouth Boot Screen                  
● systemd-vconsole-setup.service loaded failed failed Setup Virtual Console                      
● cups.socket                    loaded failed failed CUPS Scheduler                             

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.

6 loaded units listed. Pass --all to see loaded but inactive units, too.
To show all installed unit files use 'systemctl list-unit-files'.
[root@FoxMain rfox]# systemctl status cups     
● cups.service - CUPS Scheduler
   Loaded: loaded (/usr/lib/systemd/system/cups.service; enabled; vendor preset: disabled)
   Active: failed (Result: start-limit-hit) since Wed 2019-01-16 10:37:20 CET; 3min 32s ago
     Docs: man:cupsd(8)
  Process: 14773 ExecStart=/usr/sbin/cupsd -l (code=killed, signal=TERM)
 Main PID: 14773 (code=killed, signal=TERM)

Jan 16 10:37:20 FoxMain systemd[1]: Starting CUPS Scheduler...
Jan 16 10:37:20 FoxMain cupsd[14773]: Missing value on line 298 of /var/cache/cups/job.cache.
Jan 16 10:37:20 FoxMain systemd[1]: Stopped CUPS Scheduler.
Jan 16 10:37:20 FoxMain systemd[1]: cups.service: Start request repeated too quickly.
Jan 16 10:37:20 FoxMain systemd[1]: cups.service: Failed with result 'start-limit-hit'.
Jan 16 10:37:20 FoxMain systemd[1]: Failed to start CUPS Scheduler.
[root@FoxMain rfox]# systemctl start cups 
[root@FoxMain rfox]# systemctl status cups
● cups.service - CUPS Scheduler
   Loaded: loaded (/usr/lib/systemd/system/cups.service; enabled; vendor preset: disabled)
   Active: active (running) since Wed 2019-01-16 10:41:04 CET; 1s ago
     Docs: man:cupsd(8)
 Main PID: 3282 (cupsd)
   Status: "Scheduler is running..."
   CGroup: /system.slice/cups.service
           ├─3282 /usr/sbin/cupsd -l
           └─3287 /usr/lib/cups/notifier/dbus dbus://

Jan 16 10:41:04 FoxMain systemd[1]: Starting CUPS Scheduler...
Jan 16 10:41:04 FoxMain cupsd[3282]: Missing value on line 298 of /var/cache/cups/job.cache.
Jan 16 10:41:04 FoxMain systemd[1]: Started CUPS Scheduler.


Version-Release number of selected component (if applicable):
lib64cups-filters1-1.21.6-1.mga7
cups-filters-1.21.6-1.mga7
cups-drivers-foo2zjs-0.0-1.20121012.11.mga7
lib64cups2-2.2.10-1.mga7
gutenprint-cups-5.2.14-2.mga7
cups-pk-helper-0.2.6-2.mga7
python3-cups-1.9.74-2.mga7
cups-common-2.2.10-1.mga7
cups-2.2.10-1.mga7
cups-filesystem-2.2.10-1.mga7

How reproducible:
Every boot - 

Steps to Reproduce:
1.  Cleared out /var/cache/cups/
2.  de-installed and re-installed cups
3.  Problem persists
Comment 1 Robert Fox 2019-01-16 10:58:00 CET
After fresh re-install - here's the error:

[root@FoxMain rfox]# systemctl status cups
● cups.service - CUPS Scheduler
   Loaded: loaded (/usr/lib/systemd/system/cups.service; enabled; vendor preset: disabled)
   Active: failed (Result: start-limit-hit) since Wed 2019-01-16 10:54:49 CET; 34s ago
     Docs: man:cupsd(8)
  Process: 3490 ExecStart=/usr/sbin/cupsd -l (code=exited, status=0/SUCCESS)
 Main PID: 3490 (code=exited, status=0/SUCCESS)
   Status: "Scheduler is running..."

Jan 16 10:54:49 FoxMain systemd[1]: Starting CUPS Scheduler...
Jan 16 10:54:49 FoxMain systemd[1]: Stopping CUPS Scheduler...
Jan 16 10:54:49 FoxMain cupsd[3490]: Notifier for subscription 319 (dbus://) went away, retrying!
Jan 16 10:54:49 FoxMain systemd[1]: Stopped CUPS Scheduler.
Jan 16 10:54:49 FoxMain systemd[1]: cups.service: Start request repeated too quickly.
Jan 16 10:54:49 FoxMain systemd[1]: cups.service: Failed with result 'start-limit-hit'.
Jan 16 10:54:49 FoxMain systemd[1]: Failed to start CUPS Scheduler.
David Walser 2019-01-19 17:04:17 CET

Assignee: bugsquad => thierry.vignaud

Comment 2 Robert Fox 2019-02-01 13:24:57 CET
Any news / updates?  Still have this issue . . .
Comment 3 Thomas Andrews 2019-03-27 18:08:42 CET
Confirmed on my Cauldron install as of today, even after updates of cups packages. No idea how long it's been, as I have not had occasion to print for several days.

When I go to print, I have just the "print to file" option, and system-config-printer immediately appears like it tries to connect to a non-existent network printer. In MCC, System/Manage system services shows the "on boot" box beside cups as checked, but it's labeled as stopped unless I change it manually. Probably unrelated, but the "on boot" box next to the cups-browsed service is unchecked, as well.

This is completely unacceptable. Raising the priority to release blocker.

CC: (none) => andrewsfarm
Priority: Normal => release_blocker

Comment 4 David GEIGER 2019-03-27 18:24:53 CET
(In reply to Thomas Andrews from comment #3)
 
> This is completely unacceptable. Raising the priority to release blocker.

Ohhh ohhh! what is this??? please calm down your remarks!!

This is a Cauldron development release not a stable release one!!

CC: (none) => geiger.david68210

Comment 5 Thomas Andrews 2019-03-27 18:45:44 CET
(In reply to David GEIGER from comment #4)
> 
> Ohhh ohhh! what is this??? please calm down your remarks!!
> 
> This is a Cauldron development release not a stable release one!!

Agreed. And if I had run into this back when we were at the beta 1 stage, I might have been inclined to let it wait. 

But at this stage of development, when we may be contemplating an official release before long, I consider this situation unacceptable. It needs to be fixed before release, and this is the best way to make sure that happens.
Comment 6 Thomas Andrews 2019-03-27 20:06:03 CET
I have not had this issue for as long as the O.P. I had occasion to do a lot of printing on my HP usb printers from Cauldron during February, and everything was fine for me back then.

I first remember running into it on 23 March, when I attempted to print something from Firefox, and the only option available was "print to file." 

I do not recall the last time printing from Cauldron was working for me, because I did not do much of any printing during March until lately.
Comment 7 w unruh 2019-03-27 22:44:12 CET
I assume that you have your printer as the default printer. If you do 
lpstat -a
lpstat -d
is that printer there?
If you do 
lpr <filename>
does that file get printed out
It is strange, if cups is not running, that anything, including "print to file" is there. Does the "print to file" work?

On my cauldron system, cupsd is running but cups-browsed and cups/notifier/dbus
is not.
 ps auxwww |grep cups

Note that I have not had problems printing on a printer attached on my MGA7 machine, but almost all my printing is via lpr or printing from a remote system. 
I cannot get at the machine right now to see what is happening with browsers printer lists.

CC: (none) => unruh

Comment 8 w unruh 2019-03-28 01:35:28 CET
I rebooted my Mga7 machine, and again only cupsd was running, not cups-browsed or dbus running. In Okular I get the full list of printers listed, not just the Printo to file.  I cannot test chrome or netscape at present (too slow a network from that computer to what I am working on now.Ie, it does not really seem to be a problem with cups, but I do get that cups.path failed and cups.socket failed. 
The file /var/cache/cups/org.cups.cupsd does exist, though there might have been 
a race condition. 
/var/run/cups/cups.sock does exist

Looking at journalctl -b there are a number of successful invocations of cups.path and cups.socket which succeeded However there was eventually a failure after about 5th success with the 

cups.socket: Start request repeated too quickly.
Mar 27 17:05:49 tunnel.localdomain systemd[1]: cups.socket: Failed with result 'start-limit-hit'.
 
and the same with cups.path.
Comment 9 Robert Fox 2019-03-28 13:25:16 CET
Funny, I reported this in January - and now it's gaining traction . . . The problem still exists on two Cauldron related devices . . .
Comment 10 James Kerr 2019-03-28 15:41:36 CET
If my printer is powered off when I boot the system (my normal operating mode), then when I power on the printer, printing works normally.

If, however, the printer is powered on when I boot (or reboot) the system, then I see the same error as reported in comment 1, and a manual restart of cups is necessary.

CC: (none) => jim

Comment 11 w unruh 2019-03-28 18:45:55 CET
Hmm, it seems we need more info since the result is sporadic.
a) On my system, on boot with a printer (HP402dw) cupsd is running afterwards, but neither cups-browsed or the cups dbus are not running. Thus printing works fine, but I have to manually start cups-browserd which I think starts the cups dbus as well. 

Looking in the journalctl log for cups stuff, I see cups.service starting about 5 times. On the last one, both cups.path and cups.socket complain that they have been started to often too quickly, and give an error. I have no idea why cups.service is restarted so often. (see the attached journalctl -g|grep cups file). But cupsd is left running and I can print.
Comment 12 w unruh 2019-03-28 18:47:40 CET
Created attachment 10889 [details]
journalctl output on boot

This is the attachement for the previous comment.
Comment 13 Thomas Andrews 2019-03-29 23:56:02 CET
(In reply to James Kerr from comment #10)
> If my printer is powered off when I boot the system (my normal operating
> mode), then when I power on the printer, printing works normally.
> 
> If, however, the printer is powered on when I boot (or reboot) the system,
> then I see the same error as reported in comment 1, and a manual restart of
> cups is necessary.

I have two printers connected to one computer, an Officejet 6110 and a Deskjet 5650. When the Officejet is switched off, it actually is powered down and the computer doesn't see it. But when the Deskjet looks like it's switched off it's actually on standby, and the computer sees it. Perhaps that's why cups is always off when I boot.

Will try a reboot and have a look at the journal.
Comment 14 Thomas Andrews 2019-03-30 00:25:51 CET
Created attachment 10891 [details]
TJ's journal of failed cups start

The section of my journal starting just before the first mention I saw of cups and finishing with the start of sddm. Lots of cups starting and stopping here. 

Remember, there are two printers installed on this system. One should appear as connected, the other powered down.
Comment 15 Thomas Andrews 2019-04-06 21:12:20 CEST
Over the past two days I've done a major hardware upgrade on the machine that controls my printers. Newer motherboard, processor, more RAM, and an ssd boot drive. Did a clean install of Plasma from the Round 1 beta3 test isos, including a new /home, so no leftovers to confuse issues. Got updates (797 packages!), then installed my HP printers using system-config-printer through MCC.

Even after several reboots, and another new kernel or two, I am no longer seeing the problem. The cups service is running automatically each time. 

Notice, I'm not saying the problem has been fixed, only that I no longer see it. I made so many changes, in both hardware and software, that I have no idea which did the trick.
Comment 16 Thomas Andrews 2019-04-09 00:29:45 CEST
Curious. Another new install, this time from the latest round 2 of the beta3 test isos, on the same hardware, also shows the cups service as started, on every boot for several attempts. But the journal still shows several attempts to start the service, eventually ending with the same "start-limit-hit." Yet the service is running by the time Plasma is ready to work.

It would seem that this is hardware-dependent. I went from an Intel DQ45CB motherboard with a Core 2 Duo 8400 processor and 8GB of ram, booting from a rust drive, to an Intel DQ67SW motherboard with an i5 2500 processor and 16GB of RAM, booting from an ssd. The result was a considerably faster boot time. That, plus a new, clean install, are the only changes I made.

I still think this should be solved if possible before an Official release of M7, but I do not think it should hold back the beta3 release. We need to see how widespread the problem is, and the beta3 may be the best way to do it. 

If it's not particularly widespread, then perhaps the bug's priority should be downgraded again.
Comment 17 w unruh 2019-04-09 03:20:47 CEST
As I mentioned for me it is the cups.path  cups.service which are called many times successfully and eventually give that start limit failure. cupsd always worked in that it came up and was there after boot. It was cups-browsed which did not come up. That sounds like what is happening to you.

I have no idea why cups.service and cups.path are being called 10 times or so.
Comment 18 w unruh 2019-04-09 03:28:18 CEST
Sorry, that was cups.socket not cups.service that timed out.
Comment 19 Thomas Andrews 2019-04-12 16:44:13 CEST
Much of this is over my head, but...

Looking at the services listed in MCC, cups-browsed is not started, nor is it indicated that it should have been at boot. The man page indicates cups-browsed is used with remote printers, and since I have none of them it would seem to me that the current setting is correct for my system.

Looking over the newer journal again, cups.service is identified as "Cups Scheduler." I see Cups Scheduler started, and there's an attempt to configure a printer which fails, and the scheduler is stopped. It is started again, and this time a printer is configured, after which the Scheduler is stopped again. The whole process is repeated several times, until cups-socket reaches the limit. It stops with these lines:

Apr 08 17:28:09 localhost systemd[1]: Stopping CUPS Scheduler.
Apr 08 17:28:09 localhost systemd[1]: cups.socket: Start request repeated too quickly.
Apr 08 17:28:09 localhost systemd[1]: cups.socket: Failed with result 'start-limit-hit'.
Apr 08 17:28:09 localhost systemd[1]: Failed to listen on CUPS Scheduler.
Apr 08 17:28:09 localhost systemd[1]: Dependency failed for Configure Plugged-In Printer.
Apr 08 17:28:09 localhost systemd[1]: configure-printer@usb-001-005.service: Job configure-printer@usb-001-005.service/start failed with result 'dependency'.

The "printer@usb-001-005" is the one that was successfully configured in the other attempts.

My earlier journal, from before I upgraded the motherboard, failed with the following: (The usb ID is different because of which port I happened to use after the upgrade.)

Mar 29 19:00:28 localhost systemd[1]: cups.socket: Succeeded.
Mar 29 19:00:28 localhost systemd[1]: Closed CUPS Scheduler.
Mar 29 19:00:28 localhost systemd[1]: Stopping CUPS Scheduler.
Mar 29 19:00:28 localhost systemd[1]: cups.socket: Start request repeated too quickly.
Mar 29 19:00:28 localhost systemd[1]: cups.socket: Failed with result 'start-limit-hit'.
Mar 29 19:00:28 localhost systemd[1]: Failed to listen on CUPS Scheduler.
Mar 29 19:00:28 localhost systemd[1]: Dependency failed for Configure Plugged-In Printer.
Mar 29 19:00:28 localhost systemd[1]: configure-printer@usb-004-003.service: Job configure-printer@usb-004-003.service/start failed with result 'dependency'.
Mar 29 19:00:28 localhost systemd[1]: cups.service: Start request repeated too quickly.
Mar 29 19:00:28 localhost systemd[1]: cups.service: Failed with result 'start-limit-hit'.
Mar 29 19:00:28 localhost systemd[1]: Failed to start CUPS Scheduler.

Note that those last three lines, indicating that cups.service eventually failed, are not there in the newer journal.
Comment 20 Thomas Andrews 2019-04-12 16:58:53 CEST
I meant to add that I believe the repeated attempts are being caused by the printer that is connected but powered down not responding to attempts to configure it. After a certain number of attempts, cups stops trying.

It's expected that the beta3 isos will be released in a few days. 

It is my belief that if the OP does a clean install from one of those, his problem may disappear as mine did. An upgrade install *might* work, but they sometimes come with old problems that carry over. Personally, I don't recommend them - but that's up to the individual system administrator.

I'm reducing the priorty of this bug back to "normal." If it's not resolved for the OP, or if others still experience it, they should report that here and the status will be re-evaluated.

@Robert Fox: If the issue gets resolved, please let us know, so that the bug can be closed.

Priority: release_blocker => Normal

Comment 21 w unruh 2019-04-13 01:05:46 CEST
As mentioned above, my cups has the same kind of behaviour. However the printers exist (well one is the one attached printer as a double sided version (double sided ppd file) and the other is single sided. 
But I also get that the systems keeps starting and stopping until the limit is hit. cups-browsed does not start ( and in my case there is another machine with a variety of printers). nor does the cups dbus stuff. 

There is definitely something somewhat wrong, although in my case the cupsd is running after boot.
Comment 22 Martin Whitaker 2019-04-13 13:05:04 CEST
Created attachment 10921 [details]
Filtered output from journal with cups debug enabled, cups started on 3rd attempt

Just experienced this. Previous boots did not show the problem, and no packages have been updated since the last boot, so it is clearly a race during startup.

I've set the cups log level to debug, and attached the result of

  journalctl -b | grep -i "cups\|printer"

after rebooting. This time cups started on the third attempt. I'll update this the next time it hits the retry limit.

CC: (none) => mageia

Comment 23 Thomas Andrews 2019-04-13 14:49:47 CEST
Ah, a timing problem. 

That explains why my symptoms changed. Upgrading to a more modern motherboard/processor plus switching the boot drive from rust to ssd would change the timing of things. A lot.

It also explains why we aren't seeing more input from other users. You have to have just the right combination of hardware to notice it.

Good to see you checking in on this, Martin. I've been stumbling in the dark with only weak batteries to run my feeble flashlight.

I'm wondering about your opinion on the priority level for this. It's clearly serious and needs to be fixed, but I still don't think it quite reaches the level of release blocker since it seems to affect a relatively small segment of hardware. I lowered it back to "Normal," but perhaps it should have been "High."
Comment 24 Martin Whitaker 2019-04-13 17:17:38 CEST
Although cups in present on the Live ISOs, it's not started by default, so probably won't be affected by this bug. So I don't think it is a firm release blocker, but I do think we should strive to fix it before release. We don't want users finding that printing stops working when they upgrade.
Comment 25 w unruh 2019-04-13 21:55:21 CEST
Well, I am running an SSD drive as my boot drive. While I get the timeout, for cups.socket and cups.path, printing still works fine afterwards. cups.path just seems to point to a path that cups uses
PathExists=/var/cache/cups/org.cups.cupsd
and cups.socket to a socket cups listens to
ListenStream=/var/run/cups/cups.sock

Very strange.
And I agree that there seems to be a race condition, but also it is really puzzling that these two services get called so many times successfully, before they finally fail.
Comment 26 Stephen Pettin 2019-07-16 22:31:23 CEST
It seems after upgrading from 6.1 to 7 (July 13) and a few days after using my Brother MFC-5440cn AIO printer, I only saw the print option, "Print to File". I found this report about the issue with Cauldron and it seems after manually restarting Cups, the printer is seen besides "Print to File".
Just an update to this report.

My results below are from following the OP steps.

# systemctl --failed
  UNIT                                  LOAD   ACTIVE SUB    DESCRIPTION                         
● cups.path                             loaded failed failed CUPS Scheduler                      
● configure-printer@usb-004-002.service loaded failed failed Configure Plugged-In Printer        
● cpupower.service                      loaded failed failed Configure CPU power related settings
● cups.service                          loaded failed failed CUPS Scheduler                      
● fedora-loadmodules.service            loaded failed failed Load legacy module configuration    
● cups.socket                           loaded failed failed CUPS Scheduler                      

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.

6 loaded units listed. Pass --all to see loaded but inactive units, too.
To show all installed unit files use 'systemctl list-unit-files'.

# systemctl status cups
● cups.service - CUPS Scheduler
   Loaded: loaded (/usr/lib/systemd/system/cups.service; enabled; vendor preset: disabled)
   Active: failed (Result: start-limit-hit) since Mon 2019-07-15 22:47:09 CDT; 16h ago
     Docs: man:cupsd(8)
  Process: 4792 ExecStart=/usr/sbin/cupsd -l (code=exited, status=0/SUCCESS)
 Main PID: 4792 (code=exited, status=0/SUCCESS)
   Status: "Scheduler is running..."

Jul 15 22:47:09 ghostdawg1 systemd[1]: Started CUPS Scheduler.
Jul 15 22:47:09 ghostdawg1 systemd[1]: Stopping CUPS Scheduler...
Jul 15 22:47:09 ghostdawg1 systemd[1]: cups.service: Succeeded.
Jul 15 22:47:09 ghostdawg1 systemd[1]: Stopped CUPS Scheduler.
Jul 15 22:47:09 ghostdawg1 systemd[1]: cups.service: Start request repeated too quickly.
Jul 15 22:47:09 ghostdawg1 systemd[1]: cups.service: Failed with result 'start-limit-hit'.
Jul 15 22:47:09 ghostdawg1 systemd[1]: Failed to start CUPS Scheduler.
Jul 15 22:47:09 ghostdawg1 systemd[1]: cups.service: Start request repeated too quickly.
Jul 15 22:47:09 ghostdawg1 systemd[1]: cups.service: Failed with result 'start-limit-hit'.
Jul 15 22:47:09 ghostdawg1 systemd[1]: Failed to start CUPS Scheduler.

# systemctl status cups
● cups.service - CUPS Scheduler
   Loaded: loaded (/usr/lib/systemd/system/cups.service; enabled; vendor preset: disabled)
   Active: active (running) since Tue 2019-07-16 14:52:06 CDT; 54s ago
     Docs: man:cupsd(8)
 Main PID: 15538 (cupsd)
   Status: "Scheduler is running..."
   Memory: 2.2M
   CGroup: /system.slice/cups.service
           └─15538 /usr/sbin/cupsd -l

Jul 16 14:52:06 ghostdawg1 systemd[1]: Starting CUPS Scheduler...
Jul 16 14:52:06 ghostdawg1 cupsd[15538]: CreateProfile failed: org.freedesktop.DBus.Error.ServiceUnknown:The name org.freedesktop.ColorManager was not provided by any .service files
Jul 16 14:52:06 ghostdawg1 cupsd[15538]: CreateProfile failed: org.freedesktop.DBus.Error.ServiceUnknown:The name org.freedesktop.ColorManager was not provided by any .service files
Jul 16 14:52:06 ghostdawg1 cupsd[15538]: CreateDevice failed: org.freedesktop.DBus.Error.ServiceUnknown:The name org.freedesktop.ColorManager was not provided by any .service files
Jul 16 14:52:06 ghostdawg1 systemd[1]: Started CUPS Scheduler.

CC: (none) => saptech

Thomas Andrews 2019-07-20 14:17:15 CEST

Version: Cauldron => 7

Comment 27 Jeff Robins 2019-07-21 20:33:10 CEST
I also have the same issue of cups failing on boot.  This always happens for me.  I have 2 printers attached on a headless server.  Restarting after boot works fine.

CC: (none) => jeffrobinsSAE

Comment 28 r howard 2019-07-22 22:53:25 CEST
There is a duplicate of this bug at https://bugs.mageia.org/show_bug.cgi?id=25164

CC: (none) => rihoward1

Comment 29 Jeff Robins 2019-07-25 08:27:33 CEST
Additional Info, but I'm not sure if it is useful:
1) On my system where cups loads at boot
   a) cups, cups.socket and cups.path are running
2) On the system where cups fails at boot
   a) cups can be started later and runs, printing works
   b) cups.path can be started later and runs, but doesn't start when cups is restarted
   c) To get cups.socket working, cups must be stopped and then cups.socket started
Filip Komar 2019-07-30 20:53:56 CEST

CC: (none) => filip.komar

Comment 30 Thomas Andrews 2019-08-14 03:33:37 CEST
*** Bug 25164 has been marked as a duplicate of this bug. ***

CC: (none) => arbedall

Comment 31 Thomas Andrews 2019-08-14 03:46:05 CEST
Raising the priority on this again, as more and more people are reporting being hit by it.

We need to get this fixed.
Comment 32 Maurice Batey 2019-08-16 13:58:46 CEST
> We need to get this fixed.

  Yes,indeed! 

In the meantime, here on 64-bit Plasma Mga7, is there a workaround to ensure CUPS is started automatically during booting?

CC: (none) => maurice

Comment 33 Maurice Batey 2019-08-17 14:49:23 CEST
> ...is there a workaround to ensure CUPS is started automatically during 
> booting?

Actually, here it is only occasionally that CUPS has not been started during booting...
Comment 34 w unruh 2019-08-17 17:53:48 CEST
Putting 
systemctl restart cups
into rc.local  should not cause any harm. If cups is already running, then it will stop it and then start it. If it is not running, this will start it. 
Of course since we have no idea why it is not starting, I am uncertain whether this will work, and that in the stop-start scenario, that start will not fail
Ie, you might want to put in some logic into rc.local to first check to see if cups is running, before restarting/starting it. 

This is clearly a Kludge and far better is figuring out why it is sometimes, on some machines, at some phases of the moon, or at some barometric pressures, not starting.
Comment 35 Maurice Batey 2019-08-18 12:14:50 CEST
> Putting systemctl restart cups into rc.local  should not cause any harm

Seems convenient workaround. Just have to remember it is liable to get lost at the next 'clean install'.
Comment 36 Lewis Smith 2019-09-08 10:06:54 CEST
*** Bug 25406 has been marked as a duplicate of this bug. ***

CC: (none) => laidlaws

Comment 37 j pierre LAJOIE 2019-10-01 17:09:54 CEST
It's not a moon problem!
On my computer initially with MGA7 the CUPS worked well then one day it blocked, I suspected an update (?)
Not wanting every time to go through the CCM to reactivate, I removed all software containing the word CUPS!
Of course, everything has been crashed.
I reinstalled MAGEIA7 cleanly and there the CUPS started well.
No more problems .... except that since the last update of Magia the problem has reappeared.
there is something in the updates that breaks CUPS launch
Comment 38 Doug Laidlaw 2019-10-01 17:23:17 CEST
Mine was working one day, and not the next.  There may have been an update in between, but I didn't notice.  I am now on a recent reinstall from scratch of Mga 7.1, and cups is starting as it should.  I will keep a look-out.  I don't know enough to suggest a cause.  But it isn't just a quirk of my hardware, as the newsgroup tried to tell me.
Comment 39 Doug Laidlaw 2019-10-01 17:30:11 CEST
A couple of P.S.:
Hi Maurice.  I see you are on the email list.

rc.local is no longer being created by default, but I assume that it can be created.  It must be made executable.

I  use the command line much of the time.  Instead of restarting the CUPS service via MCC, I would use the command line equivalent.
Comment 40 Maurice Batey 2019-10-01 17:34:17 CEST
Thank you, Doug!
  Judging by the last week or two the problem has 'gone away :-)
Comment 41 Doug Laidlaw 2019-10-01 17:46:26 CEST
But for how long?  If Pierre is right, it will come back with the next update of Cups.
Comment 42 w unruh 2019-10-01 17:54:04 CEST
(In reply to Doug Laidlaw from comment #39)
> A couple of P.S.:
> Hi Maurice.  I see you are on the email list.
> 
> rc.local is no longer being created by default, but I assume that it can be
> created.  It must be made executable.
> 
> I  use the command line much of the time.  Instead of restarting the CUPS
> service via MCC, I would use the command line equivalent.

Well, since you have the problem and many others do not, that would suggest 
that there is something about your system which is problematic. It might be 
software, but then that should affect many others. It might be a peculiarity
of your hardware, which was why many suggested you look at that.

Yes, you could try to create /etc/rc.d/rc.local, put #!/bin/bash as the first line, then put the line into that file 
systemctl restart cups

This is a kludge but it should survive updates to cups.
Comment 43 Thomas Andrews 2019-10-01 20:32:31 CEST
(In reply to Doug Laidlaw from comment #38)
> Mine was working one day, and not the next.  There may have been an update
> in between, but I didn't notice.  I am now on a recent reinstall from
> scratch of Mga 7.1, and cups is starting as it should.  I will keep a
> look-out.  I don't know enough to suggest a cause.  But it isn't just a
> quirk of my hardware, as the newsgroup tried to tell me.

The bug IS hardware dependent, as not all hardware is affected. That doesn't mean that the bug is affecting JUST you. It affects a certain "class" of hardware. That is what you were told on Usenet.
Comment 44 j pierre LAJOIE 2019-10-02 08:07:58 CEST
(In reply to w unruh from comment #42)
> (In reply to Doug Laidlaw from comment #39)
> > A couple of P.S.:
> > Hi Maurice.  I see you are on the email list.
> > 
> > rc.local is no longer being created by default, but I assume that it can be
> > created.  It must be made executable.
> > 
> > I  use the command line much of the time.  Instead of restarting the CUPS
> > service via MCC, I would use the command line equivalent.
> 
> Well, since you have the problem and many others do not, that would suggest 
> that there is something about your system which is problematic. It might be 
> software, but then that should affect many others. It might be a peculiarity
> of your hardware, which was why many suggested you look at that.
> 
> Yes, you could try to create /etc/rc.d/rc.local, put #!/bin/bash as the
> first line, then put the line into that file 
> systemctl restart cups
> 
> This is a kludge but it should survive updates to cups.

I added the small file 'rc.local' and it corrects the problem.
But I do not think that this is a problem hardware because when I had recharged Magéia it worked well. It's good since the update that it fell into error (CUPS stopped)
there was no significant hardware or software change on my computer
Comment 45 Doug Laidlaw 2019-10-02 12:09:09 CEST
(In reply to Thomas Andrews from comment #43)
> (In reply to Doug Laidlaw from comment #38)
> > Mine was working one day, and not the next.  There may have been an update
> > in between, but I didn't notice.  I am now on a recent reinstall from
> > scratch of Mga 7.1, and cups is starting as it should.  I will keep a
> > look-out.  I don't know enough to suggest a cause.  But it isn't just a
> > quirk of my hardware, as the newsgroup tried to tell me.
> 
> The bug IS hardware dependent, as not all hardware is affected. That doesn't
> mean that the bug is affecting JUST you. It affects a certain "class" of
> hardware. That is what you were told on Usenet.

And what is the "class?"  Is it just "computers affected by the bug?"  We need to define the class, but really, the bug seems to have been created upstream.  Should we file a bug report there?

I waited until there was a second case of the same symptoms (although it was unrelated): [My bug 25406: Comment 3]  By then Pierre's report had been merged and closed, and Maurice had seen it on his box.

Unruh wrote:

"This is a kludge but it should survive updates to cups." 

Do we want it to survive an update to the upstream package that is the cause of the problem?
Comment 46 Thomas Andrews 2019-10-02 14:49:04 CEST
(In reply to Doug Laidlaw from comment #45)
> 
> And what is the "class?"  Is it just "computers affected by the bug?"  We
> need to define the class, but really, the bug seems to have been created
> upstream.  Should we file a bug report there?
> 
The answer to those questions are beyond my skill set. All I know is that I saw the problem on a Core2Duo system with rust drives, but when I upgraded to a i5-2500 with my system on an ssd the problem disappeared and never came back. 

Of course it should be fixed, but the devs need to be able to duplicate the problem to do that.

It has been suggested that there is a race condition somewhere. My experience would suggest to me that there is some hardware where that race is avoided somehow. That doesn't mean that the hardware is CAUSING the problem, only that it shows up on a limited set of hardware. If those with the skills to fix it don't have the hardware where it shows up, it makes it extremely difficult to fix. Adding to that difficulty is the intermittent factor that you have discovered.

Of course, that is small comfort to those affected. I can sympathize. I had a printing problem on Mageia 5 that showed up for me after some updates. No one could duplicate it, and it was never resolved. There was no easy workaround, other than to use a then-buggy Cauldron version of Mageia 6. Frustrating to say the least.
Comment 47 w unruh 2019-10-02 15:35:10 CEST
> 
> I added the small file 'rc.local' and it corrects the problem.
> But I do not think that this is a problem hardware because when I had
> recharged Magéia it worked well. It's good since the update that it fell
> into error (CUPS stopped)
> there was no significant hardware or software change on my computer

Whatever it is it seems to be intermittent-- which suggests some kind of 
timeout or race condition. For example your printer may just be slow in 
reporting itself tothe opeating system. That would clearly be a "hardware" 
problem (your printer). NOw one could say that it is software-- if  only cups
waited longer for the answer things would work (given my assumption above).

It might be helpful if anyone reporting this problem also told us what their printer is, so one could see if it is was one class or, or particular, printer that was problematic. If the printer was one that lots of others had who had not trouble, that would rule out printer hardware.
Comment 48 Doug Laidlaw 2019-10-02 15:59:01 CEST
Yes, I posted a terminal output that showed a race condition, but adding a delay to the Cups service file helped only for a while.  The only reliable fix was to restart the service.

I will have to leave it to you guys.  My wife and I are both ill, and that is my first priority.
Comment 49 j pierre LAJOIE 2019-10-02 16:37:40 CEST
if it's can help i use :
CONFIGURATION :
Mageia7
Noyau  linux : 5.2.16 desktop-2.mga7
64 bits
bureau Plasma KDE 5.57.0
Qt 2.12.2
reseau enp0s31f6
Processor 4xIntel CoreTM  i5-7400CPU @3.00Ghz
Memory 7.7Gio 

Printer Brother MFC-J5320DW   USB  XHCI Host Cotroler(1)
Fabricant : Brother
Numéro de série : BROG6F186606
Classe
0
((Defined at Interface level))
Sous-classe
0

Protocole
0

Version USB
2.00

ID du fabricant
0x4f9
(Brother Industries, Ltd)
ID du produit
0x343

Révision
0.00

Vitesse
480 Mbit / s

Canaux
0

Taille maximale des paquets
64
Comment 50 Doug Laidlaw 2019-10-03 10:24:48 CEST
Thanks for that, Pierre.

I am now running 8 as my main system.  Both 7 and 8 have dependency problems at the moment, but 8 is more usable for my needs.

In 8, a whole lot of Python libraries are listed to install, but so far, I seem to have only half the list.  They include libraries for cups, and may have an impact on this bug when they reach 7.
Comment 51 Leon Goldman 2019-10-06 19:25:17 CEST
I, too, had a problem with cups loading on boot in Mageia 7. It was never a problem under Mageia6. My install of 7 was an update via the mgaapplet. It was not a fresh install.

Operating System: Mageia 7
KDE Plasma Version: 5.15.4
KDE Frameworks Version: 5.57.0
Qt Version: 5.12.2
Kernel Version: 5.2.16-desktop-2.mga7
OS Type: 64-bit
Processors: 8 × Intel® Core™ i7 CPU 950 @ 3.07GHz
Memory: 11.7 GiB of RAM

CUPS would need to be manually started.

On initial boot systemctl status would yield:

Sep 28 18:07:46 localhost systemd[1]: cups.service: Main process exited, code=killed, status=15/TERM
Sep 28 18:07:46 localhost systemd[1]: cups.service: Succeeded.
Sep 28 18:07:46 localhost systemd[1]: Stopped CUPS Scheduler.
Sep 28 18:07:46 localhost systemd[1]: cups.service: Start request repeated too quickly.
Sep 28 18:07:46 localhost systemd[1]: cups.service: Failed with result 'start-limit-hit'.
Sep 28 18:07:46 localhost systemd[1]: Failed to start CUPS Scheduler.

It was fixed when I turned off my printer before booting and did not turn it on until after I had booted into Mageia7

My printer is a Brother MFC-J6710DW and it uses the drivers downloaded from the Brother web site. mfcj6710dwcupswrapper-3.0.0-1.i386.rpm

CC: (none) => leon244

Comment 52 Doug Laidlaw 2019-10-09 16:56:28 CEST
Recently, I tried to use the command line:
"cat (a text file) | lpr"

That seems to call Cups as a server.  In that mode, Cups cannot start because a .service file is missing (not a systemd file, but one of the ones with .org. in it.) It shows up in the error output, even when local printing is O.K.
Comment 53 Doug Laidlaw 2019-10-19 16:10:13 CEST
Since I last posted, there have been several upgrades of the Cups software.  Now this bug no longer shows.  That must mean that while my back was turned, some Elves came along and changed my hardware.  The fact that nobody else has posted either, can be conveniently ignored as "fake news."  Unsubscribing from this bug.
Doug Laidlaw 2019-10-19 16:10:42 CEST

CC: laidlaws => (none)

Comment 54 Jeff Robins 2019-10-23 08:37:02 CEST
I'm still having the issue and I'm up to date as of Oct 22, 2019.
Comment 55 j pierre LAJOIE 2019-10-23 08:41:17 CEST
(In reply to Jeff Robins from comment #54)

i still have the issue and i unplug et plug again my printer usb cable to start .!
Comment 56 marc laan 2019-11-06 16:25:28 CET
For what it's worth: I had the same symptoms after I upgraded from MGA 6 to 6.1, CUPS wasn't responding when I tried to print on my printer Brother DCPJ315W. It only showed "Print to file" as an option.
To get the printer working, I had to unplug & plug the usb cable, or had to start the printer AFTER the MGA system had been booted.
Then I downloaded the file "linux-brprinter-installer-2.1.1-1.gz" from the Brother website Welcome.solutions.brother.com. As root I unzipped the file "linux-brprinter-installer-2.1.1-1 DCP-J315W" and started this as root in the console. Tens of files were installed. After a reboot my printer worked again.
Like I said: for what it's worth, but maybe the problem is older than MGA 7? Maybe upstream?

CC: (none) => laan.marc

Comment 57 j pierre LAJOIE 2019-11-06 18:43:54 CET
I did these manipulations yesterday; it worked once or twice and the problem came back!
it's true that by unplugging the usb cable, it goes back or goes through the CCM / System / Manage Services by activating cups here too, but only for the current session
Comment 58 ian howarth 2019-11-26 16:40:58 CET
One more "I'm getting this after changing to 7.1", with an HP MFP (175a).   Same messages as comment #51.

cups is supposed to start on boot but doesn't.  fires up without complaint on a "service cups restart"

CC: (none) => ihowarth

Comment 59 ian howarth 2019-11-26 16:47:09 CET
p.s.  as reported by others, printer queue *does* start at boot if the printer is switched off at that time.
Comment 60 j pierre LAJOIE 2019-11-27 05:36:52 CET
(In reply to ian howarth from comment #59)
> p.s.  as reported by others, printer queue *does* start at boot if the
> printer is switched off at that time.

printer on or printer off;  on start the problem is the same !
Comment 61 Thomas Andrews 2019-11-27 15:07:07 CET
(In reply to j pierre LAJOIE from comment #60)
> (In reply to ian howarth from comment #59)
> > p.s.  as reported by others, printer queue *does* start at boot if the
> > printer is switched off at that time.
> 
> printer on or printer off;  on start the problem is the same !

That may depend on the printer. I have two older HP printers, an Officejet and a Deskjet. When the Officejet is "switched off" it actually IS off, but switch on the Deskjet only puts it into standby. The system would still see it as "on," unless power was removed.
Comment 62 Dan Fandrich 2020-01-06 10:39:44 CET
Created attachment 11443 [details]
Potential fix

This patch fixes the problem for me, by allowing the burst of starts that are causing the limit to be hit without erroring out. It may be papering over a race condition (if one exists), but I haven't seen proof that the underlying problem is a race condition to begin with. There are still errors for cups.path and cups.socket in the journal, but they seem to be harmless and could probably be fixed by applying this patch to /usr/lib/systemd/system/cups.path and /usr/lib/systemd/system/cups.socket as well.

CC: (none) => dan

Comment 63 ian howarth 2020-01-06 12:01:12 CET
Fixed it for me, too -- thanks, Dan
Comment 64 Leon Goldman 2020-01-06 14:42:35 CET
Fixed it for me
thank you, Leon
Comment 65 j pierre LAJOIE 2020-01-06 15:07:49 CET
it'seem also ok for me . thanks Dan
my file is now like this :

[Unit]
Description=CUPS Scheduler
Documentation=man:cupsd(8)
After=network.target ypbind.service
StartLimitBurst=20
[Service]
ExecStart=/usr/sbin/cupsd -l
Type=notify
Restart=on-failure

[Install]
Also=cups.socket cups.path
WantedBy=printer.target
Comment 66 j pierre LAJOIE 2020-01-10 04:28:04 CET
I confirm, since this patch, at home CUPS starts every time.
Would it be possible during a next update, the correction be made?
thanks again
Comment 67 Thomas McAtee 2020-02-14 17:41:49 CET
I would like to add a comment to this as well if I may. 

Yesterday someone asked if I would print something for them as their printer was broke. Sure. I kept having same issues that I noticed here.

 Each time I tried to print I would see the 'print to file' and nothing else. Rebooted with same thing. I wound up putting the email in my data partition and then booting to a different OS just to print the item out for him. 

Didn't matter if rebooted or not. Thought that maybe somehow it got knocked out of system. Tried to reinstall and kept getting frozen when trying to do so. 

Decided to check for bugs before filing one. Didn't want to waste anyones time by them having to combine my post and then ah telling me that I should check first. 

Came across this one and read what was going on and decided to turn my printer off(I always keep it on) and reboot. Did reboot. Turned printer back on and it worked like it was supposed to do. Could see the printer listed then and tried printing. Works good that way. 

I noticed that this was talking about Cauldron but I'm having same issue in the Mageia 7 Stable. So don't I know if there was an update to system that messed up my printer ability so that I have to turn off all the time or not. Any rate thought I would add to that as well.

CC: (none) => thomasmcatee8

Comment 68 Thomas Andrews 2020-02-14 18:12:31 CET
(In reply to Thomas McAtee from comment #67)
> 
> I noticed that this was talking about Cauldron but I'm having same issue in
> the Mageia 7 Stable. So don't I know if there was an update to system that
> messed up my printer ability so that I have to turn off all the time or not.
> Any rate thought I would add to that as well.

The comments talk about Cauldron because the problem first surfaced when Mageia 7 was still in Cauldron. When Mageia 7 was released, the "version" designation of the bug was changed from Cauldron to Mageia 7.

I don't know if the problem still exists in the current Cauldron. Nobody has brought it up one way or the other, yet.
Comment 69 Thomas McAtee 2020-02-15 00:20:27 CET
(In reply to Thomas Andrews from comment #68)
> (In reply to Thomas McAtee from comment #67)
> > 
> > I noticed that this was talking about Cauldron but I'm having same issue in
> > the Mageia 7 Stable. So don't I know if there was an update to system that
> > messed up my printer ability so that I have to turn off all the time or not.
> > Any rate thought I would add to that as well.
> 
> The comments talk about Cauldron because the problem first surfaced when
> Mageia 7 was still in Cauldron. When Mageia 7 was released, the "version"
> designation of the bug was changed from Cauldron to Mageia 7.
> 
> I don't know if the problem still exists in the current Cauldron. Nobody has
> brought it up one way or the other, yet.


So Cauldron may well be clear but somehow instead of being fixed while in Cauldron it got passed on to the Mageia Stable when it was put out then. 

My printer is a HP Officejet 5255. And the thing had been printing eversince I installed Mageia 7 when it came out with me leaving the printer on 24/7. But yesterday it was driving me nuts trying to figure out what was going on. That's why I decided to check the bug reports before posting. Good thing that I did. 

So until a fix is pushed out on some update then I'll just have to leave printer off and turn on when I need it. 

Thanks for the reply back  Thomas Andrews.
Comment 70 ian howarth 2020-02-15 09:23:50 CET
(In reply to Thomas McAtee from comment #69)

> So until a fix is pushed out on some update then I'll just have to leave
> printer off and turn on when I need it. 

Thomas, have you actually tried the fix proposed by Dan in comment 62 (and spelled out again in 65)? Seems to have worked for everyone who's tried it.

(But yes, would be good if Mageia pushed this out as an update.)
Comment 71 Thomas McAtee 2020-02-16 02:22:26 CET
(In reply to ian howarth from comment #70)
> (In reply to Thomas McAtee from comment #69)
> 
> > So until a fix is pushed out on some update then I'll just have to leave
> > printer off and turn on when I need it. 
> 
> Thomas, have you actually tried the fix proposed by Dan in comment 62 (and
> spelled out again in 65)? Seems to have worked for everyone who's tried it.
> 
> (But yes, would be good if Mageia pushed this out as an update.)

I also forgot to mention that after I got home today I decided to reinstall the printer through the MCC to get rid of the fax etc that it was showing. Didn't like the way it was listed as printer and fax so just reinstalled and got the right setup and deleted other two. So everything is working so far. If goes acting up again I'll either do the patch or that command to see what happens. 

Thanks 
Tom
Comment 72 Thomas McAtee 2020-02-16 02:24:39 CET
(In reply to ian howarth from comment #70)
> (In reply to Thomas McAtee from comment #69)
> 
> > So until a fix is pushed out on some update then I'll just have to leave
> > printer off and turn on when I need it. 
> 
> Thomas, have you actually tried the fix proposed by Dan in comment 62 (and
> spelled out again in 65)? Seems to have worked for everyone who's tried it.
> 
> (But yes, would be good if Mageia pushed this out as an update.)

But still can't firgure out what happened to the post that Bill Unruh had done a reply to me and included this part:

"
WEll, no. You can restart cups and the problem should go away.
systemctl restart cups

It seems that IF the printer is off when the system is rebooted, and IF yours
in one of the affected systems, Then this bug seems to get triggered."
Comment 73 Lewis Smith 2020-02-21 22:04:55 CET
A fix has been proposed: comment 62,
 https://bugs.mageia.org/attachment.cgi?id=11443&action=diff
in:
 /usr/lib/systemd/system/cups.service
which is provided by CUPS, read only, one additional line at the end of the [Unit] section:
 StartLimitBurst=20

Everyone who has applied & reported this change has found it effective, comments 62-66. The problem has caused grief for a long time for effected users. Is there any reason not to push the fix as an update?
As far as one can see, the file is of fixed content (comment 65 *after* the edit); if this is so, it looks eligible for an update in itself.

Raising the Priority to hopefully get this done.

I am applying it to my own system to see whether it has any -ve effect, although I normally turn my printer on after booting, and have not experienced the bug. Will try to remember to turn it on before booting...

Whiteboard: (none) => Cauldron too?
Source RPM: (none) => cups-2.2.11-2.mga7.src.rpm
Priority: Normal => High
CC: (none) => lewyssmith

Comment 74 José Jorge 2020-05-29 15:39:58 CEST
(In reply to Lewis Smith from comment #73)
> Everyone who has applied & reported this change has found it effective,
> comments 62-66. The problem has caused grief for a long time for effected
> users. Is there any reason not to push the fix as an update?

I am trying to go forward applying this workaround in MGA7 (not cauldron as no one reported it in cauldron). I have two failing systems where I will test and report here.

Suggested Advisory:
========================

Updated cups packages workaround service failing to start in some systems.

========================

Updated packages in core/updates_testing:
========================
cups-2.2.13-1.2.mga7
cups-common-2.2.13-1.2.mga7
libcups2-devel-2.2.13-1.2.mga7
libcups2-2.2.13-1.2.mga7
cups-filesystem-2.2.13-1.2.mga7

from cups-2.2.13-1.2.mga7.src.rpm

Assignee: thierry.vignaud => qa-bugs
Status: NEW => ASSIGNED
CC: (none) => lists.jjorge

José Jorge 2020-05-29 15:40:56 CEST

Whiteboard: Cauldron too? => (none)

Comment 75 David Walser 2020-05-29 16:41:06 CEST
You can't assign this bug to QA.

Assignee: qa-bugs => lists.jjorge

Comment 76 David Walser 2020-06-11 00:31:49 CEST
Fixed in:
https://advisories.mageia.org/MGASA-2020-0248.html

Resolution: (none) => FIXED
Status: ASSIGNED => RESOLVED


Note You need to log in before you can comment on or make changes to this bug.