init: support starting multiple copies of a job

Reported by Michael Goetze on 2009-09-19
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
upstart
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.

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.

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.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers