Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

legacy-printer-app server repeatedly issues messages - Unable to accept client connection: Bad file descriptor #32

Open
hill-robert opened this issue Feb 7, 2025 · 0 comments

Comments

@hill-robert
Copy link

hill-robert commented Feb 7, 2025

debug-log.txt

Environment

Artix Linux - Kernel   6.12.9
cups                   2.4.11
cups-filters           2.0.1
libcups                2.4.11
libcupsfilters         2.1.0
libppd                 2.1.0
pappl                  1.4.8 (from Arch Linux - not available in Artix)
pappl-retrofit-git     1.0b2.r12.gbd734bf (from AUR - built 2024.11.22)
legacy-printer-app-git 1.0b2.r12.gbd734bf (from AUR - built 2024.11.22)
USB-attached Samsung SCX-3205 printer, which uses Samsung-supplied PPD.

Steps to reproduce

Ensure avahi-daemon and cupsd are running.
Normally, issue "sudo legacy-printer-app server &".
To debug, issue "sudo legacy-printer-app -o log-level=debug server 2>foo.txt &".
(With this problem, the debug log file grows extremely fast, so I put it in its own one-megabyte ext3 partition to limit its growth.)
With web-browser at localhost:8000, install the Samsung-supplied PPD, and add the USB-attached SCX-3205 printer, with name "SAMSUNG".
Issue "ipptool -tv ipp://localhost:8000/ipp/print/SAMSUNG identify-printer.test".

Actual results

The identify-printer test successfully wakes the printer up (if it was on standby), and successfully identifies the printer:

[sys-hp bob ~]$ ipptool -tv ipp://localhost:8000/ipp/print/SAMSUNG identify-printer.test
"/usr/share/cups/ipptool/identify-printer.test":
    Identify-Printer:
        attributes-charset (charset) = utf-8
        attributes-natural-language (naturalLanguage) = en
        printer-uri (uri) = ipp://localhost:8000/ipp/print/SAMSUNG
        requesting-user-name (nameWithoutLanguage) = bob
        identify-actions (keyword) = sound
    Identify Printer with Sound                                          [PASS]
        RECEIVED: 72 bytes in response
        status-code = successful-ok (successful-ok)
        attributes-charset (charset) = utf-8
        attributes-natural-language (naturalLanguage) = en
[sys-hp bob ~]$

About 27 seconds later, the legacy-printer-app server suddenly starts issuing "Unable to accept client connection: Bad file descriptor" thousands of times per second (with or without log-level=debug), and must be forcefully killed.
These error messages start at line 271 [2025-02-03T04:02:41.012Z] in the attached debug log file, which has been truncated after 500 lines, which is sufficient to demonstrate the frequency of the messages.
This problem can always be reproduced at will, and the gap between the successful identify-printer test and the start of the error messages is always between 25 and 30 seconds.

Repeating the above "Steps to reproduce" with "sudo legacy-printer-app server 2>/dev/null &" (so that the server does not get slowed down by writing messages to terminal or disk), ipptool successfully identifies the printer, and then after 25 to 30 seconds "htop" suddenly shows legacy-printer-app server loading one of my two CPU cores at close to 100% (presumably writing millions of error messages to /dev/null). The other CPU core is close to 0%, which implies that there is no other "client" process repeatedly sending connection requests to the server, nor can any such connection requests be coming in from the network, from which the PC is disconnected for these tests. So the legacy-printer-app server appears to be looping all by itself.

Expected results

  1. Ideally, no error messages should be issued, and whatever is triggering them should be fixed.
  2. In the event that the legacy-printer-app server does receive an invalid client connection request, it should issue just one error message, preferably with sufficient information for the user to diagnose and fix the cause.

For what it's worth

Searching for the string "Unable to accept client connection" in both the pappl and pappl-retrofit Github repositories yields one hit:
https://github.com/michaelrsweet/pappl/blob/master/pappl/client.c#L76

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant