Launchpad Entry: packageselection-server-n-upstart-enhancements
Packages affected: upstart
Upstart has a number of deficiencies for server applications and management that have become clear since the Lucid release. We should define enhancements needed, and best practices to avoid and/or work around those issues.
Upstart provides a level of system automation and management that system v init did not before. In the 11.04 release, we have put considerable time into documenting the best ways to take advantage of this functionality. Considerable work is going into reviewing and fixing any previously done work to ensure it is operating within these best practices.
Now that upstart has been around for a while, and we have found the pitfalls of doing certain things, it is time that we review our documentation and update it with a complete list of best practices. Users are starting to contribute upstart jobs and utilize it, without knowing the best way to use Upstart in Ubuntu. In addition some of the early work that was done may need to be reviewed and fixed to operate in a more stable way.
As a system administrator, I want to know how to write upstart jobs for starting my own services and working together with the system provided upstart jobs without worrying about later releases causing issues.
As a system administrator, I want to be able to watch the system boot progress.
As an Ubuntu Developer I want to know how best to migrate packages to use Upstart instead of sysvinit. I also want to know how best to fix problems in maintainer scripts regarding upstart scripts.
As an upstream server application author, I want to know how best to write upstart scripts that will work with current and future versions of upstart and Ubuntu.
- Upstart will be changed in the future to support state tracking instead of event tracking.
- invoke-rc.d is the only way services should be managed in maintainer scripts.
Enumerate Best Practices
The current list of best practices for Upstart is spread out over a few mailing list posts, upstart's own documentation, and a few incomplete Ubuntu wiki pages. These should be consolidated into a single list with attribution which should then be reviewed by ubuntu-devel.
This wiki page will be created and include best practices for managing, creating and modifying upstart jobs from the points of view of packagers.
This wiki page will be created to document the best practices for upstart from the point of view of system administrators and application developers.
SysVinit vs. Upstart
Upstart is NOT a reimplementation of the sysvinit system. The differences, however, are not entirely clear so a discussion is needed to enumerate the differences and provide people with alternative places for things like the sysvinit script "status" command which supports service introspection.
A list of packages that have been migrated to use upstart will be created or obtained if it already exists. These packages will have their maintainer scripts reviewed to ensure they comply with the UpstartBestPractices. Bugs will be filed documenting these problems, and will be targeted for fixing before the release.
EXAMPLES section of man page
Any use cases documented in these wiki pages that are appropriate should be submitted as patches to the man pages of Upstart upstream.
There has been some misunderstanding and negative publicity of how upstart works and what it is expected to do. Once documented on the wiki's, a series of blog posts should be made to highlight its advantages and how to take advantage of them on Lucid and Natty.
Some features and/or bug fixes should be completed to accomplish the overall goals of this specification.
Plymouth should be enhanced to listen to Upstart's dbus messages about starting/stopping services and display them in the details plugin.
Some critical error messages may be lost between when a service is started and when it starts logging to its preferred logging target, and this is best handled by upstart directly. This feature request https://bugs.launchpad.net/upstart/+bug/328881 provides a way to solve this, and should be given special attention during the natty cycle to help implement and/or test it.
See work items in blueprint whiteboard.
* Logging of executed scripts/jobs cannot be improved without major upstream changes which will be part of packageselection-foundations-n-finish-upstart * State tracking rather than event tracking in upstart jobs will be fixed upstream and is a part of packageselection-foundations-n-finish-upstart