To get the on-demand daemon use concept described in the Blueprint https://blueprints.launchpad.net/ubuntu/+spec/client-1305-printing- stack-with-mobile-in-mind
working, we need working socket activation in Upstart as this is the most convenient and well tested (on Mac OS X this is standard) way to run CUPS on-demand. Without fixing Upstart we would need to add a keep-running-while-avahi- daemon-is-present mode to cupsd (avahi-daemon is present while the print dialog is open on mobile) which would be awkward and probably not accepted upstream. So it is very important to fix Upstart. Can someone mark this bug as high priority? -- 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: Fix Released 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
