You are not logged in.
Just encountered this. Removing gutenprint fixed it for me.
Offline
Just encountered this. Removing gutenprint fixed it for me.
I do not have gutenprint installed, and are still affected by this bug... even today.
My temporary solution is not to add, modify or remove printers. Or restart the cups service whenever I add/remove/modify printers. Lucky enough one do not need to that too often.
Hopefully this will be solved eventually.
Offline
so i still cannot print from a printer i've been able to print with cups for three years nows...
all i have installed is my 7460dn printer driver from aur and cups, libcups, and lib32-libcups. that's it. the same way i've been doing it prior to version 2. i always get 100% cpu usage when cups is touched. thats even trying to print.
cups 1.7 on my debian machine works like a champ... my hackintosh works... my real macbook pro and my windows laptop works.
Last edited by orlfman (2015-03-05 02:24:39)
Offline
I think, that the best solution for CUPS 2.x issue is download ours CUPS 2.x to CUPS 1.7. CUPS 2.x is still not useable for too many machines.
Offline
Upstream is claiming that this issue can't be confirmed (MacOS). Everybody is invited to recompile printing stack packages (cups, cups-filters, ghostscript, foomatic/gutenprint) and give useful debug output (gdb/strace/valgrind). I guess it will take some time until cups 2.0.x will be widely used by other distros. So we are on our own for some time.
Offline
Upstream is claiming that this issue can't be confirmed (MacOS)
Upstream is saying that all is working on MacOs, and that's it??? If they do not even care to test their software on Linux, I am hoping for a fork. For myself, I have simply downgraded to cups 1.7 (using the Arch Roll back machine) and all is working fine. I think that is what that should be done by Archlinux. Are there anyone here that need a feature in cups 2 that is not present in 1.7? I am not even aware of such features.
Last edited by olive (2015-03-06 22:06:36)
Offline
Cups 2.0.x seems to work for many users. I myself can add printers and can print pages. Only sometimes see the high load. So there's no reason to force a downgrade. Better work on solving the issue.
Offline
@AndyRTR: Ok, you're right: CUPS 2.x works for many users. And for many users it's rather unuseably. At least with adding printer. Every time when we try to connect printer or do something on web interface we have 100% CPU usage. It's not normal. It seems that every usefull info was submitted. Without even any idea what the problem is. On CUPS bugzilla that problem is noticed as "low" with any usefull idea from upstream. In Arch we haven't any idea what to do with this bug. Then it's rather a long way to solve the issue.
So if this bug will be fixed then will be a time for update CUPS to 2.x. For many people, downgrade this package is only one solution for this bug. (i.e. for me changing ServerName to localhost:631 makes CUPS completly unuseable - I cannot conect with CUPS server at all).
PS: I can show everything about my configuration and CUPS' error_log, but they are the same as it's been shown in this thread.
Offline
I think it has probably been mentioned in other threads but for me the solution was to disable the org.cups.cupsd.socket systemd service, and then enable the org.cups.cupsd.service instead. Once that was done then after rebooting I no longer got 100% cpu spikes lasting minutes at a time. I don't know if it is possible to get diagnostics for socket activation of the cups service but it seemed to be directly connected to my cpu high load problem. Avoiding socket activation made all the difference for me.
Mike C
Offline
As another person mentioned, I fixed this after my initial upgrade to CUPS 2.0 by modifying /etc/cups/client.conf and changing the ServerName entry to ServerName localhost:631. This only applies to systems that have printers connected via USB, so network printers are not affected by this problem.
Offline
@mmstick: - Yes, it's sometimes very good solution, but... if I change ServerName to localhost:631, server is unavailable (my printer is connected via USB). Then it's not a perfect and universal solution.
Offline
@mmstick: - Yes, it's sometimes very good solution, but... if I change ServerName to localhost:631, server is unavailable (my printer is connected via USB). Then it's not a perfect and universal solution.
It wouldn't be possible to not connect because localhost is your computer. Does your /etc/hosts file have the correct configuration to allow localhost to be properly mapped to 127.0.0.1? Unless you are hosting CUPS on a different port than 631, setting it to localhost:631 is all you need to do. If you have configured CUPS to run on a different port, however, change the port to reflect that. If you have CUPS being hosted from a server and are simply connecting to it as a client, change localhost to the hostname or IP address of your print server.
Last edited by mmstick (2015-03-09 20:03:54)
Offline
@mmstick. My /etc/hosts is rather correct:
#
# /etc/hosts: static lookup table for host names
#
#<ip-address> <hostname.domain.org> <hostname>
127.0.0.1 localhost.localdomain localhost evo
::1 localhost.localdomain localhost evo
# End of file
I've never done any changing to my CUPS configuration, that works perfectly on CUPS 1.7.5. and CUPS is on localhost:631 (I use it i.e for CUPS web interface). It's only one thing that is not typical: instead of org.cups.cupsd.service I use org.cups.cupsd.socket because the first one started a long time when printer isn't plugged.
Offline
You are not alone: https://bugzilla.redhat.com/show_bug.cgi?id=1179596 and Ubuntu and Debian are now also on 2.0.x in their experimental repos. So we should soon see more reports.
Offline
You are not alone (...)
Yes, I know 'bout it. And this is a question: why such untesting and problematic software isn't in Testing repo in Arch?
Offline
Because Arch isn't Debian. And Cups 2.0.x has been in testing for some time without major bug reports. Such things can always happen when
moving üackages to a wide used repo.
Offline
With the latests upgrades I have not this issue anymore, no idea what changed :-/
I arch, you arch, he arch, she arch, we arch, they arch...
Offline
Please check cups 2.0.2-2 in testing. It should solve some high load issues.
Offline
If this won't solve it please try also the new FC fix http://pkgs.fedoraproject.org/cgit/cups … 4ca8974466 - use abs to rebuild it.
Offline
Please check cups 2.0.2-2 in testing. It should solve some high load issues.
It doesn't solve the problem.
This:
If this won't solve it please try also the new FC fix http://pkgs.fedoraproject.org/cgit/cups … 4ca8974466 - use abs to rebuild it.
doesn't solve the problem, too.
Last edited by pb (2015-03-16 21:31:37)
Offline
There's more work going on. You may try the new patch and drop the sed command. http://pkgs.fedoraproject.org/cgit/cups … b46e2d4866
Offline
There's more work going on. You may try the new patch and drop the sed command. http://pkgs.fedoraproject.org/cgit/cups … b46e2d4866
I'll rather wait for final solution (I do not have that much free time for searching new commits, changing PKGBUILD's, install CUPS 2.x, check it, downgrade to CUPS 1.7.5 and so on; maybe I'll try to make PKGBUILD for GIT version of CUPS because it's a little bit less problematic to actualize and try it on weekend). Now, I'm CUPS 1.7.5 user wich is very good enough and I haven't got any problems with it.
Offline
Check version 2.0.2-3 - latest Fedora patch fixed the load for me when searching for new printers.
Offline
Hi AndyRTR,
Check version 2.0.2-3 - latest Fedora patch fixed the load for me when searching for new printers.
I can confirm this too: I just rebuilt it using ABS with the patch applied and it seems to solve the issue: no high load when searching for new printers anymore.
Offline
Check version 2.0.2-3 - latest Fedora patch fixed the load for me when searching for new printers.
Thx. It looks like it helps. CUPS leave off to consume 100% one of my CPU's core. I can manage via web interface, too (but foomatic still takes sometime large amount of CPU). I should try this solution for a longer time, but it looks like this is a solution.
Offline