Upstart Improvements for Administrators

Registered by Mark Russell on 2011-05-05

Upstart needs better management tools for system administrators. Override files are a good start (and can do much more than just disable services), but we should provide a CLI tool for common tasks like enabling/disabling services and listing what is set to start up on boot. A CLI tool like chkconfig and/or an ncurses tool like sysv-rc-conf are good comparisons.

Is there interest in jobs-admin GUI tool (https://launchpad.net/jobsadmin)? The author has also considered a CLI/ncurses interface. (https://bugs.launchpad.net/jobsadmin/+bug/613948)

Status stanza: Many system management tools (commercial and homegrown) rely on the traditional System V "status" command to determine that a service is actually running and is not just a hung process. Upstart jobs should allow for a status stanza that works similarly. Could this be covered by custom actions? (https://bugs.launchpad.net/upstart/+bug/94873)

Are there other Upstart management feature requests?

Session notes: http://summit.ubuntu.com/uds-o/meeting/foundations-o-upstart-for-admins/

Blueprint information

Status:
Not started
Approver:
Steve Langasek
Priority:
High
Drafter:
James Hunt
Direction:
Approved
Assignee:
James Hunt
Definition:
Approved
Series goal:
Accepted for oneiric
Implementation:
Unknown
Milestone target:
None

Related branches

Sprints

Whiteboard

Switched this blueprint from server to foundations. -Robbie
[jhunt] We could also consider discussing:
  - job logging facilities
  - "discoverable" boot path
  - Interactive Boot
  - Full separation of SysV and Upstart services (particularly for shutdown)

Notes from the session:

== Discussion ==

Status stanza, monitoring systems checking for service status (LSB)

First step might just be very simple "check pid" style usage
Next step could well be verifying service is still in a "good situation" i.e. hasn't crashed
On from that, possibly then looking at dependancies for the services implemented within upstart

OCF files, does the code go into the start stop service info, or does it live independantly elsewhere in other tooling?

Are upstart services for starting services or whole life managing of services?

Analyse serivce scripts that also call other services?

Services provided with possible override files so that they don't start until they're configured. Or do you just ensure that all services have a sane starting point. How do you provide the tooling to disable a service from starting when it is installed?

Possible additional stanzas?

Manual - disable the start condition
Disabled - remove all conditions

init.conf could be used to specify jobs that are disabled

Opinion that when the startup process fails, it fails hard and it's difficult to debug what's causing the problem.

Manual stepthrough of services on startup is felt to be useful, primarly for debugging, although it may help the debugging it may also actually mask a race condition, but that also is useful information and at least should ensure that the system gets into a known working state.

Networking starting is a band aid...

== Requests ==

Chkonfig style tooling or possibly within the "service" command rather than upstart directly, or even a whole new set of tools entirely :o)
 * ncurses interface
 * and command line "just do this"

Usecases and functionality include
 * is a service enabled/disabled
 * enable/disable this service
 * what is the status of this service
 * log the output/information that the upstart jobs generate, either on a 1 by 1 basis, or system wide
 * set the system to seriialise the boot process (interactive and non-interactive)
 * Also a "show me the ordrer that these services would start"

OCF (Resource Agents) Files for healthcheck specification (http://www.linux-ha.org/wiki/OCF_Resource_Agents)

== Actions ==

Work items:
[clint-fewbar] evaluate debdiff against service command that adds service for upstart jobs: TODO
[jamesodhunt] evaluate and implement ways to programmatically disable a job: INPROGRESS
[jamesodhunt] Check status of multicast af socket work: TODO
[jamesodhunt] Finish interactive boot (manual service start): TODO
[jamesodhunt] Analyse where rc stack is started (is it too early?): TODO
[clint-fewbar] Create event for "all-statically-configured-interfaces-configured" "static-network-up": DONE
[vorlon] Remember why we turned off console output: TODO
[jamesodhunt] Produce a chkconfig-style tool to enable/disable jobs and show runlevel details: TODO
[jamesodhunt] Separate upstart jobs and sysv services for shutdown: INPROGRESS

== Topics not covered ==
  - "discoverable" boot path
  - Meta language to describe service info which generates upstart/sysv/systemd config?

(?)

Work Items