lpstat -e and an error message #352
Comments
|
@debiantriage What version of CUPS is this with? It looks like the domain socket file is still present after cupsd is stopped, and if so that'd be a systemd bug... :/ |
|
@michaelrsweet I can reproduce it on Fedora 36 (CUPS-2.4.1), all units - path, socket and service - are down, but |
|
@zdohnal With the CUPS service disabled, does the domain socket file ( |
|
@michaelrsweet disabling socket unit does not remove the domain socket file at all - disabling/enabling unit removes/adds the unit into /etc/systemd/system/*.target.wants/ , stopping/starting the socket unit does not remove/add the domain socket file either - the domain socket exists, but since the unit covering it is not active, it refuses requests... at least that's how I understand it. I would need to get a systemd person for gory details if needed. To sum it up, existence of the domain socket doesn't mean cupsd will be triggered if a request comes to it. If the socket unit is deactivated, systemd probably drops anything which is sent to /run/cups/cups.sock. The reason why we don't get any error is that we don't check whether |
|
@zdohnal When CUPS is configured to use systemd, it leaves the creation and removal of sockets (including the domain socket/file) up to systemd. Standard UNIX programming practice is to REMOVE the socket file when the service is disabled/not running, and the presence of the domain socket file tells a potential client that the service is running (or will be run when you connect). So yes, it is important to report the errors in lpstat, but the error wouldn't happen if systemd would just remove the f'ing domain socket file! |
|
@michaelrsweet aha, ok - I didn't know about this programming practice... I'll contact systemd guys whether this behavior is intended. However: Either the domain socket lingers somewhere (and my stupid reproducer doesn't do the trick), or the incorrect behavior happens even if domain socket is not present. |
|
@michaelrsweet created https://bugzilla.redhat.com/show_bug.cgi?id=2063891 - we will see whether it is intended from systemd folks... |
zdohnal
added a commit
to zdohnal/cups
that referenced
this issue
Mar 14, 2022
|
@michaelrsweet @zdohnal I found https://bugzilla.redhat.com/show_bug.cgi?id=802748 The systemd.socket manaual describes a RemoveOnStop option. Does that help? |
|
@debiantriage Yes, and we should definitely be using it; launchd and other (historical) init replacement programs that support listening on sockets on behalf of services ALL have implemented this functionality by default, so I'm stunned that it isn't also the default for systemd, but then systemd does some |
|
@michaelrsweet I added |
|
@debiantriage Hmm, can you run lpstat with strace to see when it gives up? |
|
@michaelrsweet This is on cups 2.3.3op2-3. strace.txt attached. |
|
@debiantriage great find! I was looking into the manpage myself, but I haven't seen the tree for the forest... Confirmed the behavior with 2.4.1 in Fedora - after adding |
|
The directive is applied in the commit 3448c52 . |
|
Ok, the difference between Without RemoveOnStop: so the With The program is not able to find |
|
@zdohnal The EINPROGRESS is because those sockets are connecting asynchronously. We might need to update httpAddrConnect2 to set errno to EHOSTUNREACH if none of the sockets are able to connect, but the output you are seeing is consistent with a TCP/IP connection attempt on multiple addresses. |
|
I'm not entirely sure if this is related to this specific issue or not, but These two installations share no configuration and are entirely separate, If I run the local 2.2.6 scheduler, both versions of lpstat will connect Using the 2.3.3ob2 lpstat to connect via a TCP socket results in the Below are a trial run along with an strace using the 2.3.3ob2 lpstat. If this Any help would be appreciated. |
michaelrsweet
added a commit
that referenced
this issue
May 2, 2022
|
Pushed some fixes for this. |
zdohnal
added a commit
to zdohnal/cups
that referenced
this issue
Oct 13, 2023
Some kernel versions (seen in CentOS Stream 9.2 for some setups) return `EINPROGRESS` when client tries to connect to localhost:631 and cupsd is not running, and the following `poll()` times out, which causes delays for the application using libcups. The PR is my understanding of OpenPrinting#352 (comment) where you mention setting errno to EHOSTUNREACH if none of the addresses can be connected at the moment. The problem here is the code sets EHOSTUNREACH if the last errno was EINPROGRESS, but implementing saving of errnos for previous connection attempts looked not worthy of effort, since the final result is the same (client cannot connect on that address at the moment). I've implemented the same behavior for WIN32 too.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
With the cups service stopped:
brian@desktop:~$ lpstat -alpstat: Bad file descriptorbrian@desktop:~$ lpstat -ebrian@desktop:~$Doesn't this leave some doubt as to whether there are any available destinations on the local network or cups is stopped?
The text was updated successfully, but these errors were encountered: