command

[root@magaux alain4]# systemctl enable cups.service
[root@magaux alain4]#

doesn't make any improvement:
[root@magaux alain4]# systemctl status cups.service
× cups.service - CUPS Scheduler
     Loaded: loaded (/usr/lib/systemd/system/cups.service; enabled; preset: disabled)
     Active: failed (Result: exit-code) since Thu 2025-12-04 17:48:21 CET; 2min 38s ago
TriggeredBy: × cups.socket
             × cups.path
       Docs: man:cupsd(8)
   Main PID: 16376 (code=exited, status=1/FAILURE)
        CPU: 4ms

déc. 04 17:48:21 magaux systemd[1]: cups.service: Scheduled restart job, restart counter is at 5.
déc. 04 17:48:21 magaux systemd[1]: Stopped cups.service.
déc. 04 17:48:21 magaux systemd[1]: cups.service: Start request repeated too quickly.
déc. 04 17:48:21 magaux systemd[1]: cups.service: Failed with result 'exit-code'.
déc. 04 17:48:21 magaux systemd[1]: Failed to start cups.service.
[root@magaux alain4]#

Created attachment 15191 [details]
journalctl extract

furthermore, with firefox, connection with localhost:631 fails

Thank you for the report, and sorry for the angst.

(In reply to peter lawford from comment #0)
> since the update to cups-common-2.4.6-1.5.mga9.x86_64.rpm, lpq command
> return:
> [alain4@magaux ~]$ LC_ALL=C lpq
> lpq: Unable to connect to server.
This new update was for 4 cups pkgs:
  cups                           2.4.6        1.5.mga9      x86_64  
  cups-common                    2.4.6        1.5.mga9      x86_64  
  cups-filesystem                2.4.6        1.5.mga9      noarch  
  lib64cups2                     2.4.6        1.5.mga9      x86_64  
I have just installed them, will reboot to see whar happens.

CC: (none) => lewyssmith

After re-boot:

(In reply to peter lawford from comment #0)
> # systemctl status cups.service
> ○ cups.service - CUPS Scheduler
>      Loaded: loaded (/usr/lib/systemd/system/cups.service; enabled; preset:
> disabled)
>      Active: inactive (dead) (Result: exit-code) since Thu 2025-12-04
> 17:22:18 CET; 11min ago
>    Duration: 2min 11.414s
> TriggeredBy: × cups.path
>              × cups.socket
>        Docs: man:cupsd(8)
>     Process: 1131714 ExecStart=/usr/sbin/cupsd -l (code=exited,
> status=1/FAILURE)
>    Main PID: 1131714 (code=exited, status=1/FAILURE)
>         CPU: 5ms
> 
> déc. 04 17:22:18 magaux systemd[1]: cups.service: Scheduled restart job,
> restart counter is at 4.
> déc. 04 17:22:18 magaux systemd[1]: Stopped cups.service.
> déc. 04 17:22:18 magaux systemd[1]: Dependency failed for cups.service.
> déc. 04 17:22:18 magaux systemd[1]: cups.service: Job cups.service/start
> failed with result 'dependency'.
$ sudo systemctl status cups.service
● cups.service - CUPS Scheduler
     Loaded: loaded (/usr/lib/systemd/system/cups.service; enabled; preset: disabled)
     Active: active (running) since Thu 2025-12-04 21:06:18 CET; 5min ago
TriggeredBy: ● cups.socket
             ● cups.path
       Docs: man:cupsd(8)
   Main PID: 1778 (cupsd)
     Status: "Scheduler is running..."
      Tasks: 2 (limit: 9270)
     Memory: 6.9M
        CPU: 50ms
     CGroup: /system.slice/cups.service
             └─1778 /usr/sbin/cupsd -l

Rha 04 21:06:17 localhost.localdomain systemd[1]: Starting cups.service...
Rha 04 21:06:17 localhost.localdomain cupsd[1778]: Printer drivers are deprecated and will stop working in a future version of CUPS. See https://github.com/OpenPrinting/cups/issues/103
Rha 04 21:06:18 localhost.localdomain systemd[1]: Started cups.service.

So I cannot reproduce.
BTAIM passing to packagers hoping someone can decipher your problem.

In the meantime, can you try downgrading the 4 packages to the previous version 2.4.6-1.3.mga9 (or start with cups-common).

Assignee: bugsquad => pkg-bugs
Status: NEW => UNCONFIRMED
Ever confirmed: 1 => 0

I have downgraded the five packages to the version 2.4.6-1.3
cups                           2.4.6        1.3.mga9      x86_64  
  cups-common                    2.4.6        1.3.mga9      x86_64  
  cups-filesystem                2.4.6        1.3.mga9      noarch  
  lib64cups2                     2.4.6        1.3.mga9      x86_64  
  lib64cups2-devel               2.4.6        1.3.mga9      x86_64  

and after I've ran the command:
systemctl restart cups.service

and now everything works fine

Hm I wonder what is meant by that 'dependency' in Comment 0
> déc. 04 17:22:18 magaux systemd[1]: cups.service: Job cups.service/start failed with result 'dependency'.


No one else seem to have problems, at least no other report yet.

Example outputs from my workstation:

[morgan@svarten ~]$ lpq
M:Svartvit is ready
no entries

[morgan@svarten ~]$ sudo systemctl status cups.service
[sudo] lösenord för morgan: 
● cups.service - CUPS Scheduler
     Loaded: loaded (/usr/lib/systemd/system/cups.service; enabled; preset: disabled)
     Active: active (running) since Wed 2025-12-03 16:44:39 CET; 1 day 16h ago
TriggeredBy: ● cups.socket
             ● cups.path
       Docs: man:cupsd(8)
   Main PID: 1712 (cupsd)
     Status: "Scheduler is running..."
      Tasks: 2 (limit: 19095)
     Memory: 10.1M
        CPU: 10.462s
     CGroup: /system.slice/cups.service
             └─1712 /usr/sbin/cupsd -l

And I can surf to http://localhost:631

[morgan@svarten ~]$ rpm -qa | grep cups
python3-cups-2.0.1-4.mga9
cups-pk-helper-0.2.7-1.mga9
gutenprint-cups-5.3.4-4.mga9
cups-drivers-foo2zjs-0.0-1.20121012.14.mga9
cnrdrvcups-ufr2-uk-6.00-1.00
cups-pdf-3.0.2-1.mga9
lib64cups-filters1-1.28.16-6.3.mga9
cups-filters-1.28.16-6.3.mga9
lib64cups2-2.4.6-1.5.mga9
cups-common-2.4.6-1.5.mga9
cups-filesystem-2.4.6-1.5.mga9
cups-2.4.6-1.5.mga9

CC: (none) => fri

I have 3 mageia9 systems on my computer; the same occurs for all, cups-2.4.6-1.5 refuses absolutely to work, no access to http://localhost:631, but with cups-2.4.6-1.3, everything fine works

perhaps my computer's stuff, based on the chipset Intel X99, is too old

I think it would be very strange if only this specific software would have problem with a mainboard chipset.  BTW my T510 is that old too, no problem.

Could it be some driver/printer or such that you have installed that somehow is incompatible?


Looking around on the web there have been similar issue on mint, ubuntu etc, such as https://bugs.launchpad.net/ubuntu/+source/cups/+bug/2133207/comments/7

So just a shot: does it help to comment those four lines in your /etc/cups/cupsd.conf ?


*** For getting more information: ***

To read cups messages in journal recommended way is "journalctl -u cups -e"

To increase log level:
 sudo cupsctl --debug-logging
And to restore normal log level:
 sudo cupsctl --no-debug-logging
(It seems it restarts automatically to implement it.)



However that Ubuntu bug thread mentions cups log is more useful than journal
Our /var/log/cups/ is empty. It need to be enabled in /etc/cups/cups-files.conf, see this section:

# Location of the file logging all messages produced by the scheduler and any
# helper programs; may be the name "syslog". If not an absolute path, the value
# of ServerRoot is used as the root directory.  Also see the "LogLevel"
# directive in cupsd.conf.
ErrorLog syslog

And as you can read there also LogLevel can be set, in /etc/cups/cupsd.conf.
The keywords for LogLevel you can see at 
https://www.cups.org/doc/man-cupsd.conf.html


/ Note: all above I gathered from quick web search, I am no whiz on this /

Assignee: pkg-bugs => bugsquad

I had enough messages in the journal to get mine working by commenting out the
lines at the end of /etc/cups/cupsd.conf
#BrowseAddress 192.168.10.255
#BrowseOrder Deny,Allow
#BrowseDeny All
#BrowseAllow @IF(wlan0)

After that cups was able to start and http://localhost:631/ works.

CC: (none) => davidwhodgins

Thanks.

Wondering what is special with Peters and Daves installs...
Anyway it broke with latest update.

CC latest packager

Status: UNCONFIRMED => NEW
Ever confirmed: 0 => 1
CC: (none) => nicolas.salguero

Upping priority as the last update brake printing for some users.

Priority: Normal => High
Severity: normal => major

Created attachment 15193 [details]
file /etc/cups/cupsd.conf 1st system

Created attachment 15194 [details]
file /etc/cups/cupsd.conf 2nd system

(In reply to Morgan Leijström from comment #10)
> I think it would be very strange if only this specific software would have
> problem with a mainboard chipset.  BTW my T510 is that old too, no problem.
> 
> Could it be some driver/printer or such that you have installed that somehow
> is incompatible?
> 
> 
> Looking around on the web there have been similar issue on mint, ubuntu etc,
> such as
> https://bugs.launchpad.net/ubuntu/+source/cups/+bug/2133207/comments/7
> 
> So just a shot: does it help to comment those four lines in your
> /etc/cups/cupsd.conf ?
> 
> 
> *** For getting more information: ***
> 
> To read cups messages in journal recommended way is "journalctl -u cups -e"
> 
> To increase log level:
>  sudo cupsctl --debug-logging
> And to restore normal log level:
>  sudo cupsctl --no-debug-logging
> (It seems it restarts automatically to implement it.)
> 
> 
> 
> However that Ubuntu bug thread mentions cups log is more useful than journal
> Our /var/log/cups/ is empty. It need to be enabled in
> /etc/cups/cups-files.conf, see this section:
> 
> # Location of the file logging all messages produced by the scheduler and any
> # helper programs; may be the name "syslog". If not an absolute path, the
> value
> # of ServerRoot is used as the root directory.  Also see the "LogLevel"
> # directive in cupsd.conf.
> ErrorLog syslog
> 
> And as you can read there also LogLevel can be set, in /etc/cups/cupsd.conf.
> The keywords for LogLevel you can see at 
> https://www.cups.org/doc/man-cupsd.conf.html
> 
> 
> / Note: all above I gathered from quick web search, I am no whiz on this /

Commenting the four lines of /etc/cups/cupsd.conf you mentioned above fixes the problem.
Curiously, and conversely to I've posted on comment 8, on one of my system cups-2.4.6-1.5 works fine although the four lines are not commented; in both cases, the files /etc/cups/cupsd.conf seem to be different, as they should be the sames (see attachment)
Anyway, many thanks to everybody for putting attention to this problem

Assigning to our registered cups maintainer.

Assignee: bugsquad => thierry.vignaud
Summary: since update to cups-common-2.4.6-1.5.mga9.x86_64.rpm access to cups server is impossible => since update to cups-common-2.4.6-1.5.mga9.x86_64.rpm access to cups server is impossible for some users
CC: (none) => geiger.david68210, marja11

Because I have 3 mageia9 systems on my machine, I was able to observe that the 3 corresponding files /etc/cups/cupsd.conf of cups-2.4.6-1.5 were not the same from one of the system to the other: sometimes it was corrupted, sometimes not.
It's the reason for what on some of my systems,cups-2.4.6-1.5 normally work and on some others it did'nt
You'll find the correct one in attachment.

Created attachment 15195 [details]
correct file /etc/cups/cupsd.conf for cups-2.4.6-1.5

Making some questions...
Do the corrupted files have the same kind of corruption?
Can you attach an example of bad cupsd.conf?
What tool(s) should write cupsd.conf?
Could it be that it was created long time ago, and statements in it is not valid for the new cups version?

(In reply to Morgan Leijström from comment #20)
> Making some questions...
> Do the corrupted files have the same kind of corruption?
> Can you attach an example of bad cupsd.conf?
> What tool(s) should write cupsd.conf?
> Could it be that it was created long time ago, and statements in it is not
> valid for the new cups version?

correct file is already attached; you'll find the bad file as attached doc

Created attachment 15196 [details]
bad file /etc/cups/cupsd.conf

Forum thread
https://forums.mageia.org/en/viewtopic.php?t=15795

I had to comment out 4 strange lines at the end of my cupsd.conf file, like so.

</Policy>
# JobPrivateAccess default
# JobPrivateValues default
# SubscriptionPrivateAccess default
# SubscriptionPrivateValues default

I also had to change the parameter for MaxLogSize from 0 to 1m, like so.

Previous bad line 
MaxLogSize 0

New good line
MaxLogSize 1m

*** NOW IT WORKS on my system.

CC: (none) => hankivy

Tip to see status and some log, from forum thread (thanks doktor5000)

 systemctl status cups.service -al -n50

(In reply to Morgan Leijström from comment #7)
> Hm I wonder what is meant by that 'dependency' in Comment 0
> > déc. 04 17:22:18 magaux systemd[1]: cups.service: Job cups.service/start failed with result 'dependency'.
> 
> 
> No one else seem to have problems, at least no other report yet.
> 
> Example outputs from my workstation:
> 
> [morgan@svarten ~]$ lpq
> M:Svartvit is ready
> no entries
> 
> [morgan@svarten ~]$ sudo systemctl status cups.service
> [sudo] lösenord för morgan: 
> ● cups.service - CUPS Scheduler
>      Loaded: loaded (/usr/lib/systemd/system/cups.service; enabled; preset:
> disabled)
>      Active: active (running) since Wed 2025-12-03 16:44:39 CET; 1 day 16h
> ago
> TriggeredBy: ● cups.socket
>              ● cups.path
>        Docs: man:cupsd(8)
>    Main PID: 1712 (cupsd)
>      Status: "Scheduler is running..."
>       Tasks: 2 (limit: 19095)
>      Memory: 10.1M
>         CPU: 10.462s
>      CGroup: /system.slice/cups.service
>              └─1712 /usr/sbin/cupsd -l
> 
> And I can surf to http://localhost:631
> 
> [morgan@svarten ~]$ rpm -qa | grep cups
> python3-cups-2.0.1-4.mga9
> cups-pk-helper-0.2.7-1.mga9
> gutenprint-cups-5.3.4-4.mga9
> cups-drivers-foo2zjs-0.0-1.20121012.14.mga9
> cnrdrvcups-ufr2-uk-6.00-1.00
> cups-pdf-3.0.2-1.mga9
> lib64cups-filters1-1.28.16-6.3.mga9
> cups-filters-1.28.16-6.3.mga9
> lib64cups2-2.4.6-1.5.mga9
> cups-common-2.4.6-1.5.mga9
> cups-filesystem-2.4.6-1.5.mga9
> cups-2.4.6-1.5.mga9

The same problem here. I have HP 4729 and now printer is no longer detected.

CC: (none) => adelson.oliveira

(In reply to Henry Ivy from comment #24)
> I had to comment out 4 strange lines at the end of my cupsd.conf file, like
> so.
> 
> </Policy>
> # JobPrivateAccess default
> # JobPrivateValues default
> # SubscriptionPrivateAccess default
> # SubscriptionPrivateValues default
> 
> I also had to change the parameter for MaxLogSize from 0 to 1m, like so.
> 
> Previous bad line 
> MaxLogSize 0
> 
> New good line
> MaxLogSize 1m
> 
> *** NOW IT WORKS on my system.

I've tried these changes on /etc/cups/cupsd.conf and did not work yet.

After downgrading to 2.4.6-1.3.mga9 packages, everything is working now.

Peter Lawford reported inconsistent upgraded cupsd.conf files, in comment 18. Some good, some bad. That was my CLUE.

Responsible for my own system, I downloaded both of Peter Lawford's cupsd.conf files.  Yes, both the good and the bad. I then used tools such as tkdiff to compare my cupsd.conf, and both of his files. Then I used a process of common sense and elimination to find a cupsd.conf file that worked for me.

Unfortunately, I suspect that Peter Lawford's comment number 18 is correct, and there is a flaw somewhere in the mirrors of the software upgrade system. If so, then currently, only God knows how many different versions of cupsd.conf files are in the system.

--------------

Please ignore the following rant. For my own emotional well being, I had to post it. 

If I were paid, and held responsible for making this work correctly every time; I would start by focusing on Peter Lawford's comment number 18. He reported that his THREE Mageia systems did not get upgraded to the same version of cupsd.conf. They were different. I would investigate the value of cupsd.conf on every mirror of the upgrade systems. But I am not responsible at that level of global system software for Mageia. For 30 years I did that for Texas Instruments, and Hewlett Packard. Sorry about the rant.

Thank you everybody for the researched & tried comments.

CC: lewyssmith => (none)

I believe something rewrites cupsd.conf on users systems.

And that something is not compatible with current cups.

Comparing the date of cups.conf and install time of cups they are different:

[morgan@svarten ~]$ ll /etc/cups/cupsd.conf
-rw-r----- 1 root lp 4595 dec  5 20:18 /etc/cups/cupsd.conf

[morgan@svarten ~]$ rpm -qa --last | grep cups
lib64cups2-2.4.6-1.5.mga9.x86_64              ons  3 dec 2025 11:25:54
cups-filesystem-2.4.6-1.5.mga9.noarch         ons  3 dec 2025 11:25:54
cups-common-2.4.6-1.5.mga9.x86_64             ons  3 dec 2025 11:25:54
cups-2.4.6-1.5.mga9.x86_64                    ons  3 dec 2025 11:25:54
cups-filters-1.28.16-6.3.mga9.x86_64          lör 22 nov 2025 18:51:29
lib64cups-filters1-1.28.16-6.3.mga9.x86_64    lör 22 nov 2025 18:51:28
cups-pdf-3.0.2-1.mga9.x86_64                  lör 12 apr 2025 12:12:24
cnrdrvcups-ufr2-uk-6.00-1.00.x86_64           lör  7 sep 2024 11:40:54
cups-drivers-foo2zjs-0.0-1.20121012.14.mga9.x86_64 mån  1 maj 2023 00:28:42
gutenprint-cups-5.3.4-4.mga9.x86_64           mån  1 maj 2023 00:28:41
cups-pk-helper-0.2.7-1.mga9.x86_64            fre 28 apr 2023 16:45:09
python3-cups-2.0.1-4.mga9.x86_64              fre 28 apr 2023 16:45:06

I believe as manual fix accepted users can use /etc/cups/cupsd.conf.default, similar to https://bugs.launchpad.net/ubuntu/+source/cups/+bug/2133207/comments/44

---

@packager: Bug is fixed in Ubuntu
https://bugs.launchpad.net/ubuntu/+source/cups/+bug/2133207 comments 45+

Status comment: Workaround: comments 11, 24 => Comments: manual fix 11, 24, 32, fixed in Ubuntu 32

This need to be addressed!
Broke printing for some users.

No response from packager, thus assigning all.

CC: (none) => thierry.vignaud
Assignee: thierry.vignaud => pkg-bugs

Created attachment 15245 [details]
Patch from Ubuntu to fix the issue

Hi,

I found that Ubuntu added that patch to fix the problem.  Sadly, I have no access to a machine running Mageia until the end of the week. Can someone try to add/backport that patch, please?

Best regards,

Nico.

cups-2.4.6-1.6.mga9 should solve that issue.  See bug 34900.

Can somebody confirm if the issue is fixed after update to cups-2.4.6-1.6.mga9 ?

I've just updated cups files. It seems it is fine now.

(In reply to Adelson Oliveira from comment #37)
> I've just updated cups files. It seems it is fine now.

Great.
Thank you for the feedback.

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