init: needs a way to define startup priorities

Reported by sven on 2010-01-15
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
upstart
Wishlist
Unassigned

Bug Description

Upstart needs some clear way to define whether jobs should start early or late, and before or after another job in the boot process. To put it short it needs a priority value for jobs like the old ordering of startup scripts by name.

For a fast startup on desktop systems I want all desktop related jobs to start before server jobs. Currently, there seems to be no easy way to achieve this. Jobs with little event dependencies for startup simply come first which is ok for server systems, but not for desktop systems.

E.g. mythtv-backend comes with a startup script that only depends on local-filesystems so it gets started very early which is not desirable for desktop systems. It should startup only after gdm (and user session) have finished loading. i.e. all jobs need a priority field to put them early or late in the boot while respecting event dependencies.

And second: when do upstart jobs get started in respect to legacy init.d scripts which have not been converted, yet? I wonder how I can force mysql server, for example, to start up later in the boot process.

Regards
Sven

sven (post-svennielsen) on 2010-01-15
description: updated

The way I'm thinking about doing this is with advisory stanzas that would only take effect if both jobs were actually ready to be started at the same time.

Changed in upstart:
status: New → Triaged
importance: Undecided → Wishlist
summary: - upstart needs a way to define startup priorities
+ init: needs a way to define startup priorities
sven (post-svennielsen) wrote :

Hi Scott,

i'm no developer only hobby admin, so sorry if i dont use precise terms.

I dont know the exact logic of new init process, but I think advisory stanzas at second priority would only suffice partially. Jobs with lesser dependencies would still always come first. Advisory stanzas need to have priority over event dependencies. So, evaluate the advisory stanza first. If an arbitrary job specifies an advisory stanza, all jobs which this job depends on, will then inherit the first jobs "level" recursively, thus keeping event dependancy and also postponing all other jobs that specify a lower or no advisory stanza.

Other discussion has taken place that would place jobs in priority groups; if at any point a job in a higher priority group is transitioning, those in lower priority groups are "delayed"

e.g. if an event started 6 jobs, 3 high priority and 3 low priority; the 3 high priority would get started, and the 3 low priority delayed until the high priority jobs were all running

If another event occurred with high priority jobs, the low priority jobs would get deferred further

sven (post-svennielsen) wrote :

Yes, priority groups sounds like a good way to put job starting in order.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers