[2.4.9 regression] cupsd don't start when only Listen /path/to/domain/socket is set in conf #985
Comments
|
Sounds like a configuration problem - systemd is supposed to supply the domain socket to cupsd when running on-demand. |
|
I use the default cups.service and cups.socket provided from this repo. |
|
If I remove |
|
The |
|
Ok, we did not count the possibility the Listen for socket is the only Listen directive in the cupsd.conf. In that case, the Listen line for .sock is ignored, thus the service is not started. @michaelrsweet probably we have to move |
|
Or do not let the loading fail - I'll look into the code. |
Even if there are two Listen directives and the service start does cups listen on both or is socket no-op? |
|
@michaelrsweet A added 6131f6a on top of 2.4.9 but unfortunately it still fails with the same error: |
|
The difference is it fails later than before: Previously it failed right after reading the config: |
|
OK, so that tells me there is an issue with the systemd configuration - the change I pushed delays the error message until we have queried systemd for its listen sockets... |
|
I have the systemd socket active before cups is started: Something connecting to that socket triggers cups startup but then it fails with the usual error. |
|
Here's the excerpt from the log with I don't know if BTW: is the |
|
I made another test - this time I removed The logs is identical to one before - so the Or maybe it expects at least one valid |
|
@Maryse47 Can you test against the current Github master or 2.4.x branch? The log messages indicate that service_checkin was able to add the listener from systemd but the subsequent error message indicates otherwise. I added a different message for the service_checkin failure so we'd know where the problem was getting reported. Thanks! |
…ng#985) If only cups.sock is set as listener in cupsd.conf, the array Listeners was NULL. To prevent copying the code, move the array allocation earlier and have only one check for Listeners, in `service_checkin()` which is run every time cupsd starts. Fixes OpenPrinting#985
If only the expected cups.sock is set as listener in cupsd.conf, the array Listeners was NULL. To prevent copying the code, do the array allocation earlier and have only one check for Listeners, in service_checkin() which is run every time cupsd starts. Fixes OpenPrinting#985
|
Here's excerpt from log using 2.4.x git branch: |
If only the expected cups.sock is set as listener in cupsd.conf, the array Listeners was NULL. To prevent copying the code, do the array allocation earlier and have only one check for Listeners, in service_checkin() which is run every time cupsd starts. Fixes OpenPrinting#985
If only the expected cups.sock is set as listener in cupsd.conf, the array Listeners was NULL. To prevent copying the code, do the array allocation earlier and have only one check for Listeners, in service_checkin() which is run every time cupsd starts. Fixes OpenPrinting#985
If only the expected cups.sock is set as listener in cupsd.conf, the array Listeners was NULL. To prevent copying the code, do the array allocation earlier and have only one check for Listeners, in service_checkin() which is run every time cupsd starts. Fixes #985
If cups is started with no network listeners, i.e., only with `Listen /path/to/unix.socket` lines in cupsd.conf, it fails to start. This is caused by the patch of CVE-2024-35235, see also bdf63d7 dfe9603 Upstream documented the problem here OpenPrinting/cups#985 and fixed it here OpenPrinting/cups#988 . In NixOS, the problem manifests itself with this configuration: > services.printing.listenAddresses = []; The commit at hand adds three more patches from the upstream repository. This is the smalles possible change that fixes the regression caused by the initial patch.
Add two new vm tests for the printing configuration that test `listenAddresses = []`, i.e., the situation where cups only listens on the unix domain socket `/run/cups/cups.sock`. This helps catching bugs like this: OpenPrinting/cups#985 NixOS#337748
Add two new vm tests for the printing configuration that test `listenAddresses = []`, i.e., the situation where cups only listens on the unix domain socket `/run/cups/cups.sock`. This helps catching bugs like this: OpenPrinting/cups#985 NixOS#337748
Add two new vm tests for the printing configuration that test `listenAddresses = []`, i.e., the situation where cups only listens on the unix domain socket `/run/cups/cups.sock`. This helps catching bugs like this: OpenPrinting/cups#985 NixOS#337748
Add two new vm tests for the printing configuration that test `listenAddresses = []`, i.e., the situation where cups only listens on the unix domain socket `/run/cups/cups.sock`. This helps catching bugs like this: OpenPrinting/cups#985 NixOS#337748
Describe the bug
Setting cupsd to listen only on socket path prevents cups daemon from starting. It worked in 2.4.8 and before and stopped working in 2.4.9.
If the only
Listendirective incupsd.confis set to socket path like:Listen /run/cups/cups.sockthen cupsd daemon fails to start when running from systemd:
cups.service: Failed with result 'protocol'.The cups error log shows:
No valid Listen or Port lines were found in the configuration file.To Reproduce
Steps to reproduce the behavior (on ArchLinux):
/etc/cups/cupsd.confand remove any otherListendirective thanListen /run/cups/cups.socksystemct start cups.socketsystemctl start cupscups.service: Failed with result 'protocol'.andNo valid Listen or Port lines were found in the configuration file.error messagesExpected behavior
I expect cupsd service to start like before
System Information:
OS: ArchLinux
Cups 2.4.9
Additional context
By reading changelog I presume it's somewhat related to a436956 but the listening on socket functionality is still present in cups and I don't know what users are supposed to do to make it work.
The text was updated successfully, but these errors were encountered: