Three comments about this: * can the $UPSTART_FDS still be gotten even if $UPSTART_EVENTS is not socket? That way we could add some other start event and still get socket activation.
* If so, would it be a good idea to add a "or usb-device-added ID_MODEL=USB_Printer" to the start on, to make the delay of CUPS starting even more invisible to the user? (WARNING: have not confirmed that USB_Printer ID_MODEL can be relied upon consistently, that is just what I got in upstart monitor when I plugged in my printer). * Finally, I think the default exit on idle should be more than 30 seconds; more like a minute, maybe 1:30. This would have big benefits to the UX with a tiny impact on battery life IMO. -- 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: Invalid 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 : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
