[opensuse] Cups does not start automatically.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 When I try to print something, after booting, the list of printers does not appear in Libre Office or gimp. Telcontar:~ # systemctl status cups.service ● cups.service - CUPS Printing Service Loaded: loaded (/usr/lib/systemd/system/cups.service; enabled; vendor preset: enabled) Active: inactive (dead) Telcontar:~ # Telcontar:~ # systemctl status cupsd.service ● cups.service - CUPS Printing Service Loaded: loaded (/usr/lib/systemd/system/cups.service; enabled; vendor preset: enabled) Active: inactive (dead) Telcontar:~ # Telcontar:~ # systemctl status cups.socket ● cups.socket Loaded: not-found (Reason: No such file or directory) Active: inactive (dead) Telcontar:~ # There is no message related to cups in /var/log/messages since the last boot. I thought that starting cups would be automatic, when needed, but in my case it is enabled, should be running fulltime. Apparently it also needs colord Telcontar:~ # systemctl status colord.service ● colord.service - Manage, Install and Generate Color Profiles Loaded: loaded (/usr/lib/systemd/system/colord.service; static; vendor preset: disabled) Active: inactive (dead) Telcontar:~ # systemctl start cups.service Telcontar:~ # systemctl status cups.service ● cups.service - CUPS Printing Service Loaded: loaded (/usr/lib/systemd/system/cups.service; enabled; vendor preset: enabled) Active: active (running) since Mon 2017-01-30 19:37:03 CET; 20s ago Main PID: 8361 (cupsd) Tasks: 1 (limit: 512) CGroup: /system.slice/cups.service └─8361 /usr/sbin/cupsd -f Jan 30 19:37:03 Telcontar systemd[1]: Started CUPS Printing Service. Telcontar:~ # systemctl status colord.service ● colord.service - Manage, Install and Generate Color Profiles Loaded: loaded (/usr/lib/systemd/system/colord.service; static; vendor preset: disabled) Active: active (running) since Mon 2017-01-30 19:37:04 CET; 28s ago Main PID: 8366 (colord) Tasks: 3 (limit: 512) CGroup: /system.slice/colord.service └─8366 /usr/lib/colord Jan 30 19:37:04 Telcontar systemd[1]: Starting Manage, Install and Generate Color Profiles... Jan 30 19:37:04 Telcontar systemd[1]: Started Manage, Install and Generate Color Profiles. Jan 30 19:37:05 Telcontar colord[8366]: (colord:8366): Cd-WARNING **: failed to get session [pid 8361]: No such device or address Jan 30 19:37:05 Telcontar colord[8366]: (colord:8366): Cd-WARNING **: failed to get session [pid 8361]: No such device or address Jan 30 19:37:05 Telcontar colord[8366]: (colord:8366): Cd-WARNING **: failed to get session [pid 8361]: No such device or address Telcontar:~ # Log: 3.6> 2017-01-30 19:37:03 Telcontar systemd 1 - - Started CUPS Printing Service. <3.5> 2017-01-30 19:37:04 Telcontar dbus 1440 - - [system] Activating via systemd: service name='org.freedesktop.ColorManager' unit='colord.service' <3.6> 2017-01-30 19:37:04 Telcontar systemd 1 - - Starting Manage, Install and Generate Color Profiles... <3.5> 2017-01-30 19:37:04 Telcontar dbus 1440 - - [system] Successfully activated service 'org.freedesktop.ColorManager' <3.6> 2017-01-30 19:37:04 Telcontar systemd 1 - - Started Manage, Install and Generate Color Profiles. <3.6> 2017-01-30 19:37:05 Telcontar colord 8366 - - (colord:8366): Cd-WARNING **: failed to get session [pid 8361]: No such device or address <3.6> 2017-01-30 19:37:05 Telcontar colord 8366 - - message repeated 2 times: [ (colord:8366): Cd-WARNING **: failed to get session [pid 8361]: No such device or address] <3.6> 2017-01-30 19:37:09 Telcontar systemd 1 - - Time has been changed Then when I try to print a message pops up saying that there is a missing printer, but nevertheless it prints. Now, what must I do so that cups does start on boot? Or a minute later, doesn't matter. I have to start it manually, some times several times till it holds. - -- Cheers Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAliPiiYACgkQtTMYHG2NR9VYMgCdFqTN7EmcDcIGvAi3z1lZcczr b0oAnAzLBVKdEKe+0rT68u+EyI0zdFlY =CFT1 -----END PGP SIGNATURE-----
On 01/30/2017 10:46 AM, Carlos E. R. wrote:
Now, what must I do so that cups does start on boot? Or a minute later, doesn't matter. I have to start it manually, some times several times till it holds.
Cups.service needs these to start:
requires: sysinit.target(active), system.slice(active) conflicts: shutdown.target(dead) wanted by: multi-user.target(active) after: basic.target(active), network.target(active), sysinit.target(active), system.slice(active), systemd-journald.socket(running) before: multi-user.target(active), shutdown.target(dead)
Note this is the inheritied requirements as well as the direct requirements. The cups.service is actually quite simple:
[Unit] Description=CUPS Printing Service After=network.target
[Service] ExecStart=/usr/sbin/cupsd -f
[Install] WantedBy=multi-user.target
One of the conditions (or inherited conditions) listed above is not coming true, or shutdown.target is not going away. Are you shutting down, or are you suspending? Is your network slow to start? -- After all is said and done, more is said than done.
On 2017-01-30 23:09, John Andersen wrote:
On 01/30/2017 10:46 AM, Carlos E. R. wrote:
Now, what must I do so that cups does start on boot? Or a minute later, doesn't matter. I have to start it manually, some times several times till it holds.
Cups.service needs these to start:
requires: sysinit.target(active), system.slice(active) conflicts: shutdown.target(dead) wanted by: multi-user.target(active) after: basic.target(active), network.target(active), sysinit.target(active), system.slice(active), systemd-journald.socket(running) before: multi-user.target(active), shutdown.target(dead)
Note this is the inheritied requirements as well as the direct requirements. The cups.service is actually quite simple:
[Unit] Description=CUPS Printing Service After=network.target
[Service] ExecStart=/usr/sbin/cupsd -f
[Install] WantedBy=multi-user.target
One of the conditions (or inherited conditions) listed above is not coming true, or shutdown.target is not going away. Are you shutting down, or are you suspending? Is your network slow to start?
The problem arises after a full reboot. If I activate the service manually, then hibernate, cups stays alive, I think. Network is not using dhcp on this machine. systemd-analyze blame: 20.590s wicked.service -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
Carlos E. R. wrote:
On 2017-01-30 23:09, John Andersen wrote:
On 01/30/2017 10:46 AM, Carlos E. R. wrote:
Now, what must I do so that cups does start on boot? Or a minute later, doesn't matter. I have to start it manually, some times several times till it holds.
Cups.service needs these to start:
requires: sysinit.target(active), system.slice(active) conflicts: shutdown.target(dead) wanted by: multi-user.target(active) after: basic.target(active), network.target(active), sysinit.target(active), system.slice(active), systemd-journald.socket(running) before: multi-user.target(active), shutdown.target(dead)
Note this is the inheritied requirements as well as the direct requirements. The cups.service is actually quite simple:
[Unit] Description=CUPS Printing Service After=network.target
[Service] ExecStart=/usr/sbin/cupsd -f
[Install] WantedBy=multi-user.target
One of the conditions (or inherited conditions) listed above is not coming true, or shutdown.target is not going away. Are you shutting down, or are you suspending? Is your network slow to start?
The problem arises after a full reboot. If I activate the service manually, then hibernate, cups stays alive, I think.
As you would expect, right?
Network is not using dhcp on this machine.
systemd-analyze blame: 20.590s wicked.service
That seems pretty normal. When your cups doesn't start automatically or you have to keep trying manually, surely there are messages and logs that will tell you what's going on. If not, I would try starting cups from the command line, perhaps with strace. One problem I have occasionally seen is that services that depend on DNS/network to be available will not be able to start if they're started before DNS is available. -- Per Jessen, Zürich (3.2°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2017-02-04 09:31, Per Jessen wrote:
When your cups doesn't start automatically or you have to keep trying manually, surely there are messages and logs that will tell you what's going on.
That's the problem, nothing to be seen. Nothing in journal, nothing in messages log. As I may notice 5 days after boot, the journal may have rotated already.
If not, I would try starting cups from the command line, perhaps with strace.
But then it starts. The problem is having it started automatically on boot so that when I want to print, it prints. Programs say that there are no printers, that's when I know that it did not start. I would have to hack the service file with strace; but I have the suspicion that systemd doesn't even try to start it. If the cups daemon crashed or something there would be evidence in the logs, and there is nothing. I suspect that even though I want cups to start on boot, it doesn't and waits on cups.socket instead.
One problem I have occasionally seen is that services that depend on DNS/network to be available will not be able to start if they're started before DNS is available.
Well... -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
Carlos E. R. wrote:
On 2017-02-04 09:31, Per Jessen wrote:
When your cups doesn't start automatically or you have to keep trying manually, surely there are messages and logs that will tell you what's going on.
That's the problem, nothing to be seen. Nothing in journal, nothing in messages log.
So the main indication is that cupsd isn't running? pidof cupsd? (not seeing any printers could have other reasons). Anything in /var/log/cups/error_log ?
If not, I would try starting cups from the command line, perhaps with strace.
But then it starts.
Okay, so in normal operation there is no problem, it's only during start-up.
The problem is having it started automatically on boot so that when I want to print, it prints. Programs say that there are no printers, that's when I know that it did not start.
Okay.
I would have to hack the service file with strace; but I have the suspicion that systemd doesn't even try to start it.
I meant starting it manually with strace, but you could also try adding it to the service file. You don't need to hack anything, you just override it with a drop-in. I'm not sure how to determine if systemd tries to start it or not - "systemd-analyze critical-chain cups" maybe? # systemd-analyze critical-chain cups.service The time after the unit is active or started is printed after the "@" character. The time the unit takes to start is printed after the "+" character. cups.service @21.819s └─network.target @21.800s └─wicked.service @1.138s +20.661s └─wickedd-nanny.service @1.124s +12ms └─wickedd.service @1.091s +9ms └─wickedd-dhcp4.service @987ms +90ms └─dbus.service @891ms └─basic.target @855ms └─sockets.target @855ms └─dbus.socket @855ms └─sysinit.target @854ms └─apparmor.service @172ms +681ms └─systemd-journald.socket └─-.slice
I suspect that even though I want cups to start on boot, it doesn't and waits on cups.socket instead.
On my Leap422 client, there is no cups.socket. -- Per Jessen, Zürich (4.1°C) http://www.hostsuisse.com/ - virtual servers, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2017-02-05 10:03, Per Jessen wrote:
Carlos E. R. wrote:
On 2017-02-04 09:31, Per Jessen wrote:
When your cups doesn't start automatically or you have to keep trying manually, surely there are messages and logs that will tell you what's going on.
That's the problem, nothing to be seen. Nothing in journal, nothing in messages log.
So the main indication is that cupsd isn't running? pidof cupsd? (not seeing any printers could have other reasons).
The first indication I notice is when I try to print some document, that I can only print to file, say in Libre Office. I then use "rccup status" and it says that it not running. I then investigate a bit, but being in a hurry to print that document I end by starting the service manually.
Anything in /var/log/cups/error_log ?
I'd have to reboot to find out.
If not, I would try starting cups from the command line, perhaps with strace.
But then it starts.
Okay, so in normal operation there is no problem, it's only during start-up.
Right.
The problem is having it started automatically on boot so that when I want to print, it prints. Programs say that there are no printers, that's when I know that it did not start.
Okay.
I would have to hack the service file with strace; but I have the suspicion that systemd doesn't even try to start it.
I meant starting it manually with strace, but you could also try adding it to the service file. You don't need to hack anything, you just override it with a drop-in. I'm not sure how to determine if systemd tries to start it or not - "systemd-analyze critical-chain cups" maybe?
The time after the unit is active or started is printed after the "@" character. The time the unit takes to start is printed after the "+" character. cups.service @1d 19h 21min 25.342s └─network.target @1min 50.734s └─wicked.service @1min 30.138s +20.590s └─wickedd-nanny.service @1min 29.954s +160ms └─wickedd.service @1min 29.758s +171ms └─wickedd-auto4.service @1min 29.205s +492ms └─SuSEfirewall2_init.service @1min 21.163s +7.977s └─basic.target @1min 20.209s └─sockets.target @1min 20.204s └─dbus.socket @1min 20.200s └─sysinit.target @1min 20.130s └─cryptsetup.target @1min 20.125s └─systemd-cryptsetup@cr_cripta.service @9.569s +1min 10.548s └─dev-disk-by\x2duuid-00424b7c\x2d8294\x2d4359\x2db44c\x2d8ae5d9a2d452.device @9.438s
# systemd-analyze critical-chain cups.service The time after the unit is active or started is printed after the "@" character. The time the unit takes to start is printed after the "+" character.
cups.service @21.819s └─network.target @21.800s └─wicked.service @1.138s +20.661s └─wickedd-nanny.service @1.124s +12ms └─wickedd.service @1.091s +9ms └─wickedd-dhcp4.service @987ms +90ms └─dbus.service @891ms └─basic.target @855ms └─sockets.target @855ms └─dbus.socket @855ms └─sysinit.target @854ms └─apparmor.service @172ms +681ms └─systemd-journald.socket └─-.slice
I suspect that even though I want cups to start on boot, it doesn't and waits on cups.socket instead.
On my Leap422 client, there is no cups.socket.
Ah. That's a clue. Telcontar:~ # systemctl status cups[TAB][TAB] cups-browsed.service cups.path cups.service cups.socket cupsd.service Telcontar:~ # systemctl status cups.socket ● cups.socket Loaded: not-found (Reason: No such file or directory) Active: inactive (dead) Telcontar:~ # Telcontar:~ # locate cups.socket /CopiaSeguridadParcial/etc/systemd/system/sockets.target.wants/cups.socket /etc/systemd/system/sockets.target.wants/cups.socket <========= /etc_13.1/systemd/system/sockets.target.wants/cups.socket /other/test_a2/etc/systemd/system/sockets.target.wants/cups.socket /other/test_a2/usr/lib/systemd/system/cups.socket /root/Upgrades/Del_12.1_al_12.3/copia aux_01 para borrar luego/etc/systemd/system/sockets.target.wants/cups.socket Telcontar:~ # Telcontar:~ # l /etc/systemd/system/sockets.target.wants/cups.socket lrwxrwxrwx 1 root root 35 Jun 9 2013 /etc/systemd/system/sockets.target.wants/cups.socket -> /usr/lib/systemd/system/cups.socket Telcontar:~ # Telcontar:~ # l /usr/lib/systemd/system/cups.socket ls: cannot access '/usr/lib/systemd/system/cups.socket': No such file or directory Telcontar:~ # It seems a leftover that was not cleared by the system upgrade :-( I'll delete it. Telcontar:~ # systemctl status cups.[TAB][TAB] cups.path cups.service cups.socket Telcontar:~ # systemctl status cups.socket ● cups.socket Loaded: not-found (Reason: No such file or directory) Active: inactive (dead) Telcontar:~ # I have to tell systemd to reread things, but I don't remember how. And then I have to try a reboot. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
On 2017-02-05 16:43, Carlos E. R. wrote:
On 2017-02-05 10:03, Per Jessen wrote:
And then I have to try a reboot.
No, the problem remains. Telcontar:~ # systemctl status cups.service ● cups.service - CUPS Printing Service Loaded: loaded (/usr/lib/systemd/system/cups.service; enabled; vendor preset: enabled) Active: inactive (dead) Telcontar:~ # systemctl status cupsd.service ● cups.service - CUPS Printing Service Loaded: loaded (/usr/lib/systemd/system/cups.service; enabled; vendor preset: enabled) Active: inactive (dead) Telcontar:~ # Nothing in the cups logs: Telcontar:~ # ls -ltr /var/log/cups/ total 3644 -rw-r--r-- 1 root lp 1048604 May 12 2011 access_log.O -rw-r--r-- 1 root lp 1048599 Mar 28 2013 error_log.O -rw-r--r-- 1 root lp 753357 Feb 4 20:15 error_log -rw-r--r-- 1 root lp 201127 Feb 4 20:15 page_log -rw-r--r-- 1 root lp 667155 Feb 4 20:15 access_log Telcontar:~ # date Sun Feb 5 22:20:40 CET 2017 Telcontar:~ # Telcontar:~ # grep cups /var/log/messages Telcontar:~ # grep -i cups /var/log/messages ... <3.5> 2017-01-30 19:41:19 Telcontar dbus 1440 - - [system] Successfully activated service 'org.opensuse.CupsPkHelper.Mechanism' <3.6> 2017-02-05 22:08:29 Telcontar systemd 1 - - Stopping CUPS Printing Service... Telcontar:~ # That's when I halted the machine. After booting, nothing. Telcontar:~ # journalctl | grep -i cups Telcontar:~ # So, systemd certainly does not attempt to start cups on boot. Why? Telcontar:~ # systemctl start cups Telcontar:~ # systemctl status cups ● cups.service - CUPS Printing Service Loaded: loaded (/usr/lib/systemd/system/cups.service; enabled; vendor preset: enabled) Active: active (running) since Sun 2017-02-05 22:24:17 CET; 4s ago Main PID: 14048 (cupsd) Tasks: 1 (limit: 512) CGroup: /system.slice/cups.service └─14048 /usr/sbin/cupsd -f Feb 05 22:24:17 Telcontar systemd[1]: Started CUPS Printing Service. Telcontar:~ # -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
On 2017-02-05 22:25, Carlos E. R. wrote:
So, systemd certainly does not attempt to start cups on boot. Why?
Now it works. I did disable, then enable, rebooted because I had done some updates via yast, and on the boot, this time it worked. Telcontar:~ # systemctl status cups ● cups.service - CUPS Printing Service Loaded: loaded (/usr/lib/systemd/system/cups.service; enabled; vendor preset: enabled) Active: active (running) since Sun 2017-02-05 22:32:38 CET; 5min ago Main PID: 2361 (cupsd) Tasks: 1 (limit: 512) CGroup: /system.slice/cups.service └─2361 /usr/sbin/cupsd -f Feb 05 22:32:38 Telcontar systemd[1]: Started CUPS Printing Service. Telcontar:~ # "cupsd.service" has now disapeared from the list of available services, though. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
Carlos E. R. wrote:
On 2017-02-05 22:25, Carlos E. R. wrote:
So, systemd certainly does not attempt to start cups on boot. Why?
Now it works. I did disable, then enable, rebooted because I had done some updates via yast, and on the boot, this time it worked.
Telcontar:~ # systemctl status cups ● cups.service - CUPS Printing Service Loaded: loaded (/usr/lib/systemd/system/cups.service; enabled; vendor preset: enabled) Active: active (running) since Sun 2017-02-05 22:32:38 CET; 5min ago Main PID: 2361 (cupsd) Tasks: 1 (limit: 512) CGroup: /system.slice/cups.service └─2361 /usr/sbin/cupsd -f
Feb 05 22:32:38 Telcontar systemd[1]: Started CUPS Printing Service. Telcontar:~ #
"cupsd.service" has now disapeared from the list of available services, though.
On Leap422 I don't have a cupsd anyway. From your postings, the unit was the same - /usr/lib/systemd/system/cups.service. -- Per Jessen, Zürich (1.8°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2017-02-06 07:40, Per Jessen wrote:
Carlos E. R. wrote:
"cupsd.service" has now disapeared from the list of available services, though.
On Leap422 I don't have a cupsd anyway. From your postings, the unit was the same - /usr/lib/systemd/system/cups.service.
Well, this is 42.2 and I had it. Apparently the upgrade from 13.1 left things dangling. I have the feeling that this did not occur with init.d, but I do not know for certain >:-) -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
participants (3)
-
Carlos E. R. -
John Andersen -
Per Jessen