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
Documentation of ListenBackLog in cupsd.conf doesn't seem accurate #5975
Comments
@ioMatrix You are correct that ListenBacklog no longer does anything, and in fact it hasn't done anything since at least CUPS 1.7 (a little over 8 years ago). I'll update the documentation to list it as no longer supported and we'll pull it completely from 2.4.0 over in OpenPrinting CUPS. |
michaelrsweet
added a commit
that referenced
this issue
Oct 1, 2021
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
There is an issue with the documentation for the CUPS configuration. Notably ListenBackLog.
ListenBackLog number
Specifies the number of pending connections that will be allowed. This normally only affects very busy servers that have reached the MaxClients limit but can also be triggered by large numbers of simultaneous connections. When the limit is reached, the operating system will refuse additional connections until the scheduler can accept the pending ones. The default is the OS-defined default limit, typically either "5" for older operating systems or "128" for newer operating systems.
This sounds all good until you see the following tracing of the listen call of the TCP ports during application start...
Going into the application source code, it's obvious that the listen buffer is hard coded to 5 in versions of CUPS pre 2.3.5:
Line 248 of /cups/http-addr.c ----> listen(fd, 5)
So, the version of CUPS we are using is setting a backlog of 5 as you can see here:
Version 2.3.5 release notes say the listen buffer (Send-Q) is now hard coded 128. Although an improvement, this is still a discrepancy from the documented ListenBackLog variable which says the default is the OS-defined limit.
Can someone correct me if I am out to lunch here?
The text was updated successfully, but these errors were encountered: