Cups socket activation fails
To save resources I tried to switch to the CUPS socket activation setup. According to the Arch Wiki (https://wiki.archlinux.org/title/CUPS#Socket_activation) two steps are necessary for this (enable cups.socket and disable cups.service). # systemctl enable --now cups.socket Created symlink /etc/systemd/system/sockets.target.wants/cups.socket → /etc/systemd/system/cups.socket. # systemctl disable --now cups.service Removed /etc/systemd/system/sockets.target.wants/cups.socket. # systemctl status cups.socket ● cups.socket - CUPS Scheduler Loaded: loaded (/etc/systemd/system/cups.socket; disabled; vendor preset: enabled) Active: inactive (dead) Triggers: ● cups.service Listen: /run/cups/cups.sock (Stream) [::]:631 (Stream) Unfortunately the connection to CUPS fails (at least after reboot), both with the browser (http://localhost:631/) and with tools like "lpstat". "systemctl start cups.service" of course solves this, but socket activation should work without enabling the service unit itself. What is wrong here or is this function buggy in openSUSE TW? I use the a current TW installation. Greetings, Björn
On 02/07/2021 10.12, Bjoern Voigt wrote:
To save resources I tried to switch to the CUPS socket activation setup.
According to the Arch Wiki (https://wiki.archlinux.org/title/CUPS#Socket_activation) two steps are necessary for this (enable cups.socket and disable cups.service).
# systemctl enable --now cups.socket Created symlink /etc/systemd/system/sockets.target.wants/cups.socket → /etc/systemd/system/cups.socket. # systemctl disable --now cups.service Removed /etc/systemd/system/sockets.target.wants/cups.socket. # systemctl status cups.socket ● cups.socket - CUPS Scheduler Loaded: loaded (/etc/systemd/system/cups.socket; disabled; vendor preset: enabled) Active: inactive (dead) Triggers: ● cups.service Listen: /run/cups/cups.sock (Stream) [::]:631 (Stream)
Unfortunately the connection to CUPS fails (at least after reboot), both with the browser (http://localhost:631/) and with tools like "lpstat". "systemctl start cups.service" of course solves this, but socket activation should work without enabling the service unit itself.
What is wrong here or is this function buggy in openSUSE TW? I use the a current TW installation.
Several years ago, when the migration to systemd was done, my machine got cups socket activation by default. It did not work. There was a thread about it. I at least changed the default to service enabled always, instead, and never tried back. Since then I installed other machines afterwards, and I don't recall problems. I see two machines with both service and target enabled and active. Both on Leap. -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)
* Carlos E.R. <robin.listas@gmx.es> [07-02-21 04:26]:
On 02/07/2021 10.12, Bjoern Voigt wrote:
To save resources I tried to switch to the CUPS socket activation setup.
According to the Arch Wiki (https://wiki.archlinux.org/title/CUPS#Socket_activation) two steps are necessary for this (enable cups.socket and disable cups.service).
# systemctl enable --now cups.socket Created symlink /etc/systemd/system/sockets.target.wants/cups.socket → /etc/systemd/system/cups.socket. # systemctl disable --now cups.service Removed /etc/systemd/system/sockets.target.wants/cups.socket. # systemctl status cups.socket ● cups.socket - CUPS Scheduler Loaded: loaded (/etc/systemd/system/cups.socket; disabled; vendor preset: enabled) Active: inactive (dead) Triggers: ● cups.service Listen: /run/cups/cups.sock (Stream) [::]:631 (Stream)
Unfortunately the connection to CUPS fails (at least after reboot), both with the browser (http://localhost:631/) and with tools like "lpstat". "systemctl start cups.service" of course solves this, but socket activation should work without enabling the service unit itself.
What is wrong here or is this function buggy in openSUSE TW? I use the a current TW installation.
Several years ago, when the migration to systemd was done, my machine got cups socket activation by default. It did not work. There was a thread about it. I at least changed the default to service enabled always, instead, and never tried back.
Since then I installed other machines afterwards, and I don't recall problems. I see two machines with both service and target enabled and active. Both on Leap.
fwiw: I also am recently having problems with cups.socket stopping and have to restart it to print. But I have no idea what you did to enable cups.socket "always". please elaborate -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday, 2021-07-02 at 09:14 -0400, Patrick Shanahan wrote:
* Carlos E.R. <> [07-02-21 04:26]:
On 02/07/2021 10.12, Bjoern Voigt wrote:
To save resources I tried to switch to the CUPS socket activation setup.
According to the Arch Wiki (https://wiki.archlinux.org/title/CUPS#Socket_activation) two steps are necessary for this (enable cups.socket and disable cups.service).
# systemctl enable --now cups.socket Created symlink /etc/systemd/system/sockets.target.wants/cups.socket → /etc/systemd/system/cups.socket. # systemctl disable --now cups.service Removed /etc/systemd/system/sockets.target.wants/cups.socket. # systemctl status cups.socket ● cups.socket - CUPS Scheduler Loaded: loaded (/etc/systemd/system/cups.socket; disabled; vendor preset: enabled) Active: inactive (dead) Triggers: ● cups.service Listen: /run/cups/cups.sock (Stream) [::]:631 (Stream)
Unfortunately the connection to CUPS fails (at least after reboot), both with the browser (http://localhost:631/) and with tools like "lpstat". "systemctl start cups.service" of course solves this, but socket activation should work without enabling the service unit itself.
What is wrong here or is this function buggy in openSUSE TW? I use the a current TW installation.
Several years ago, when the migration to systemd was done, my machine got cups socket activation by default. It did not work. There was a thread about it. I at least changed the default to service enabled always, instead, and never tried back.
Since then I installed other machines afterwards, and I don't recall problems. I see two machines with both service and target enabled and active. Both on Leap.
fwiw: I also am recently having problems with cups.socket stopping and have to restart it to print. But I have no idea what you did to enable cups.socket "always". please elaborate
On these two machines I did nothing, just configure the printer once. I simply run the usual systemctl command: Isengard:~ # systemctl status cups.service ● cups.service - CUPS Scheduler Loaded: loaded (/usr/lib/systemd/system/cups.service; enabled; vendor preset: enabled) Active: active (running) since Sat 2021-05-15 15:44:12 CEST; 1 months 17 days ago Docs: man:cupsd(8) Main PID: 1191 (cupsd) Tasks: 1 CGroup: /system.slice/cups.service └─1191 /usr/sbin/cupsd -l May 15 15:44:12 Isengard systemd[1]: Started CUPS Scheduler. Isengard:~ # systemctl status cups.socket ● cups.socket - CUPS Scheduler Loaded: loaded (/usr/lib/systemd/system/cups.socket; enabled; vendor preset: enabled) Active: active (running) since Sat 2021-05-15 15:44:12 CEST; 1 months 17 days ago Listen: /run/cups/cups.sock (Stream) May 15 15:44:12 Isengard systemd[1]: Listening on CUPS Scheduler. Isengard:~ # You can see that the vendor preset is "enabled" on both. At some time in the distant past, when systemd was brought to openSUSE, cups service was disabled by default, and the socket was active. The idea was that when something wanted to print, the "socket" thing would activate the "service" thing. This did not work, and I and others decided to "enable" the service, which results in having the thing loaded or active always, not on request. And time later, this became the default on openSUSE. - -- Cheers, Carlos E. R. (from openSUSE 15.2 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iHoEARECADoWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCYN9E0hwccm9iaW4ubGlz dGFzQHRlbGVmb25pY2EubmV0AAoJELUzGBxtjUfVdb8An1WwSvD9kDdTu5q50/0h 8HT47A/2AJ9F4eq7FoYnfa2MM2Ye+OxjDr/6MA== =50nj -----END PGP SIGNATURE-----
participants (4)
-
Bjoern Voigt -
Carlos E. R. -
Carlos E.R. -
Patrick Shanahan