Upstart roadmap
(Renamed from foundations-
= Summary =
General discussion on the direction Upstart is heading in.
= Ideas =
- interactive boot.
- full Upstart and SysV segregation (+ Upstart controlled shutdown).
- event log for problem determination.
- 'initctl kill <signal> <job>'
- enabling user jobs.
- introducing user job logging.
- mountall plans.
- custom actions.
- cron replacement.
- conditional start/stop on condition, based on whether a particular job is available for. Examples being:
- dovecot+postfix
- nis+autofs
- ...?
= References =
- https:/
- https:/
- https:/
= Blueprints =
- https:/
- https:/
- https:/
- https:/
- https:/
Blueprint information
- Status:
- Not started
- Approver:
- Steve Langasek
- Priority:
- Medium
- Drafter:
- James Hunt
- Direction:
- Approved
- Assignee:
- James Hunt
- Definition:
- Approved
- Series goal:
- Accepted for raring
- Implementation:
-
Not started
- Milestone target:
- None
- Started by
- Completed by
Whiteboard
From the etherpad...
Welcome to Ubuntu Developer Summit!
#uds-p #track #topic
put your session notes here
= userjobs =
for user events, you have to start a user session in upstart
* this already exists, as opt-in
* should we enable this by default?
* prefix job names in the display (initctl limitation)
* "console log" does not work in user job - will gracefully degrade to "console none".
(code is 99% done, but not yet packaged (missing tests too).
* two logins by the same user, should we have two jobs?!
* user jobs should support multiple sessions
* ability to run login shell for user jobs? currently need to explicitly source ~/.bash* / set DISPLAY for example.
* can a user write an override file for a system job for that user? prolly not! :)
* stateful re-exec required for upgrading upstart/
= things to discuss =
* interactive boot.
* full Upstart and SysV segregation (+ Upstart controlled shutdown).
* event log for problem determination.
* 'initctl kill <signal> <job>'
* enabling user jobs.
* introducing user job logging.
* mountall plans.
* custom actions.
= After wrong expect =
* how to recover? with/without rebooting
(http://
* how to prevent this ever happening ? (slangasek has a branch)
(http://
(how to establish fork count can be misleading with 'funny' daemons)
= Actions =
[scott] write up what the right way of doing cgroups are (DONE)
(see https:/
[vorlon] fix the ptrace branch and land it
create an abstract job/event for primary-
- review existing jobs with >3 events for start/stop on conditions since signifies overly-complex
condition (lightdm, plymouth*, udev-fallback-
= priorities =
The Ptrace Problem™
stateful restart
= upstart re-exec and state dump/load =
it did exist in the past ~0.3, got dropped due to maintainance cost
There should be a cgroup verb, but we need a formal heirarchy of how cgroups are laid out
(concern: introducing a 'cgroup' verb would be Linux-specific (what about 'oom' too?))
serializing for re-exec: events, jobs, instances, for purposes of forward declaration
libdbus: in the dbus loop call dispatch_message, and once the queue is empty we know we have no state there to care about
Work Items
Work items:
[scott] Write up what the right way of doing cgroups are: DONE
[jamesodhunt] Work with apw, raof, rancell, cjwatson, slangasek, pitti, etc to understand fully the existing udev events for graphics devices: TODO
[jamesodhunt] Document precisely what graphics-
[jamesodhunt] Create a "primary-
[jamesodhunt] Add primary-
[jamesodhunt] Simplify lightdm and plymouth-splash upstart jobs to make use of primary-
