You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
Ideally, no error messages should be issued, and whatever is triggering them should be fixed.
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.
debug-log.txt
Environment
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:
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
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
The text was updated successfully, but these errors were encountered: