init: support starting multiple copies of a job
Bug #433270 reported by
Michael Goetze
This bug affects 1 person
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| upstart |
Triaged
|
Wishlist
|
Unassigned | ||
Bug Description
Currently, I can't see a way to automatically start jobs with an "instance" declaration. This makes the oft-cited getty example rather useless. A syntax such as
start TTY=tty2 on runlevel [23]
start TTY=tty3 on runlevel [23]
etc.
would be nice.
Revision history for this message
| Scott James Remnant (Canonical) (canonical-scott) wrote | #1 |
| Changed in upstart: | |
| importance: | Undecided → Wishlist |
| status: | New → Triaged |
| summary: |
- init: needs a possiblity to autostart multiinstance jobs + init: support starting multiple copies of a job |
To post a comment you must log in.
One of the problems is how do you define why the instances are difference in the first place? Your getty example isn't actually correct, since getty can be instanced based on the tty keyword, for example:
start on tty-device-added KERNEL=tty[23] and runlevel [23]
stop on tty-device-removed KERNEL$KERNEL and runlevel [!23]
instance $KERNEL
(in the 0.6 model)
In the 0.10 model, this would be just:
while tty-device KERNEL=tty[23] and runlevel [23]
the instantiation is automatic.
But this doesn't help when you aren't binding to specific ttys, for example if you use getty with openvt:
exec openvt getty
And you want two gettys, but you don't care which consoles they end up on. We should support that somehow.