Committed cups 1.7.1-5 to the Debian GIT repository of CUPS. This
contains the changes on cupsd to support triggering the daemon by the
Upstart socket bridge and in addition changes for cupsd to terminate if
it gets idle (no jobs, no shared printers). The package will appear in
Trusty as soon as it is uploaded to Debian and then auto-synced to
Ubuntu.
** Changed in: cups (Ubuntu)
Status: Confirmed => In Progress
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to cups in Ubuntu.
https://bugs.launchpad.net/bugs/1276713
Title:
upstart socket activation for cups
Status in Upstart:
Confirmed
Status in “cups” package in Ubuntu:
In Progress
Bug description:
tkamppeter and I, worked on porting cups to use socket activation.
There were a few issues:
cups by default, binds to "localhost:631" it does it by resolving
localhost and then binding to all IP address there were returned, so
by default it does ::1 and 127.0.0.1.
Once that configuration option is established a list of sockets is
generated, we've modified initialisation to look at UPSTART_FDS
(similar to uwsgi) and replace matching sockets passed to us into the
list.
This appears to work fine, apart from it appeared as if sockets passed
by upstart to us are bound to 0.0.0.0 regardless of the configuration
(or so getsockname tells cups).
Secondly since upstart only gives us one socket, i opted to modify
cups config to explicitely listen on ipv4 127.0.0.1 and disabled the
unix domain socket option, such that clients socket activate cups and
communicate via that socket.
After doing all of the above, we noticed that although cups is started
and is managed by upstart and cups logs indicate that it apparently
has resumed accepting connections.... but there is already a client
connection / request pending which activated cups in the first place.
After inspecting netstat it was apparent that connection has
buffered/unprocessed packets still waiting for a reply. Eventually a
client that socket activated cups timesout and exits, and subsequent
connections work correctly. I believe that we didn't increment "client
connection count" to one in CUPS state-machine or some such.
Following example code within upstart which performs lauchd socket
activation was not useful either, as that code path is clearly buggy,
since it incorrectly checks for error/return codes of getsockname.
I'll attach the state of our patch work to this bug report.
I dislike, how "accepting connections" is paused/resumed and how cups
does dns resolution and thus listens on more connections than
configured to. I think best way to proceed is to instead investigate
and patch unix domain socket activation for cups, as hopefully that is
slightly more reliable from the upstart-socket-bridge.
The bug of not processing the first connection, i presume, is in cups
codebase - unless we are required to replay the messages.
To manage notifications about this bug go to:
https://bugs.launchpad.net/upstart/+bug/1276713/+subscriptions
--
Mailing list: https://launchpad.net/~desktop-packages
Post to : [email protected]
Unsubscribe : https://launchpad.net/~desktop-packages
More help : https://help.launchpad.net/ListHelp
