Server application enhancements for upstart and upstart best practices

Registered by Clint Byrum on 2010-10-12

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.

Blueprint information

Status:
Complete
Approver:
Robbie Williamson
Priority:
Essential
Drafter:
Clint Byrum
Direction:
Approved
Assignee:
Clint Byrum
Definition:
Approved
Series goal:
Accepted for natty
Implementation:
Implemented
Milestone target:
milestone icon ubuntu-11.04-beta-1
Started by
Clint Byrum on 2010-12-07
Completed by
Robbie Williamson on 2011-04-28

Related branches

Sprints

Whiteboard

Status: examples by stanza sent to upstart-devel, working with jamesodhunt on upstart-events page for events specification. Begun work on upstart-cookbook w/ jamesodhunt: lp:~clint-fewbar/+junk/upstart-cookbook and lp:~jamesodhunt/+junk/upstart-cookbook . Several Items blocked on initial announcement/release of upstart cookbook.

Work items for natty-alpha-2:
Produce existing best practices list and email ubuntu-devel for approval/discussion: DONE
Email ubuntu-devel about where to move code from sysvinit 'status' commands when transitioning a service to upstart: DONE
[jamesodhunt] Review existing upstart events and specify the correct use of each (handled mostly by jamesodhunt's upstart-intro): DONE
Identify types of jobs (expect fork, task, etc) and provide a good example of each: DONE

Work Items for natty-alpha-3:
Review existing ubuntu related upstart documentation for errors or ambiguities: POSTPONED

Work Items:
Review existing ubuntu related upstart documentation for errors or ambiguities: DONE
Document Upstart best practices fully on wiki.ubuntu.com: DONE
Document Upstart best practices for users on help.ubuntu.com: DONE
Provide links to help in Ubuntu Server Guide: INPROGRESS
Link planned bug fixes from UbuntuSpec:packageselection-foundations-n-finish-upstart to workarounds from documentation: POSTPONED
Submit documentation updates to ubuntu-devel for review: DONE
Correct documentation and provide pointers to best practices document: DONE
Publicize upstart job writing best practices via blogs: POSTPONED
Follow UbuntuSpec:packageselection-foundations-n-finish-upstart fix status and adapt documentation: DONE
Review maintainer scripts of packages that recommend packages that have upstart jobs for incorrect usage of initctl: POSTPONED
Submit use cases as EXAMPLES to upstart man pages: POSTPONED
[cjwatson] extend plymouth to listen to upstart's dbus interface for jobs being started/stopped, and report this in details plugin: DONE

Notes from UDS session:

* Best practices for upstart jobs - document and list them
 * Conffiles - should upstart jobs be software or configuration or both?
   - [action] document upstart job best practices (should be small/simple)
   - /etc/default was created because changing scripts in /etc/init.d often caused hideous merges (cjwatson)
   - suggestion: provide framework for an "override" file, which are nonexistent by default, concatenated to the end of the conffile upstart, in /etc/init/local/*
 * Logging in upstart jobs
   - upstream fix: stdout/stderr proxied through init to [initctl/logging daemon/etc]
   - no "refactor" required; could be done by anyone; couple of weeks work
 * Maintainer scripts should NOT use start/stop -- invoke-rc.d needs to provide consistent return codes for upstart jobs.
   - planned fix has been documented at a previous UDS upstart session (ask keybuk or slangasek to find this). exists somewhere on wiki.u.c (need to find)
   - no they shouldn't - slangasek
 * Stability/reproducibility in boot
   - upstream working on this during the refactor
 * Server boot process - making it admin friendly
   - plymouth takes output, upstart needs to publish meaningful output to plymouth (see upstart logging item above)
   - have plymouth listen to upstart's dbus interface, and have the details plugin report jobs being started in a traditional format
 * Status from upstart does not offer introspection like sysvinit scripts do; need a way for scripts to supply an arbitrary script that upstart would run after looking for the process, which can determine if the service is actually in a usable state
   * DustinKirkland has a patch to the service command that does this, but it would be ideal if Upstart supported it properly
   - post-start stanza can be made to check the service validity after the pid starts
 * Return code of start/stop/restart/status should be more indicative (Puppet, for instance, has modules for dealing with sysvinit that are totally broken by the start/stop/restart command's return codes.
 * How to programmatically disable a service

(?)

Work Items