upstart

compat: sysv-rc not console owner

Bug #211402 reported by Matt Zimmerman on 2008-04-03

Affects		Status	Importance	Assigned to	Milestone
	upstart	Won't Fix	Low	Unassigned
	upstart (Ubuntu)	Fix Released	Low	Unassigned

Bug Description

When running under upstart, the sysv rc scripts don't seem to be able to receive terminal input or signals. I observed this in that it's impossible to interrupt fsck with Control-C, though I expect this affects other scripts as well.

Related branches

lp:~ubuntu-core-dev/upstart/ubuntu

lp:ubuntu/lucid/upstart

Revision history for this message

Matt Zimmerman (mdz) wrote on 2008-04-03:

<mdz> I also noticed I was unable to ^C fsck; I'm pretty sure that used to work ages ago
<mdz> Keybuk: did that change with upstart?
<Keybuk> mdz: yes
[...]
<Keybuk> mdz: there is an unexplained difference in behaviour between Upstart and sysvinit when it comes to the ownership of /dev/consoe
<Keybuk> unexplained in that the code is identical, but produces different behaviour
[...]
<Keybuk> mdz: if Upstart gives sys-rc "ownership" of the console, then X will crash
<Keybuk> so "telinit 3" while running X becomes disasterous

Scott James Remnant (Canonical) (canonical-scott) on 2008-06-02

Changed in upstart:
importance:	Undecided → Low
status:	New → Confirmed

Scott James Remnant (Canonical) (canonical-scott) on 2008-10-24

Changed in upstart:
importance:	Undecided → Low
status:	New → Confirmed

Scott James Remnant (Canonical) (canonical-scott) on 2009-06-18

summary:	- Cannot interact with sysv-rc (e.g. fsck) + compat: jobs not console owner
summary:	- compat: jobs not console owner + compat: sysv-rc not console owner

Revision history for this message

Scott James Remnant (Canonical) (canonical-scott) wrote on 2009-06-18:

Actually, there's no reason that rcS can't be "console owner" - it's not ever run during X!

Changed in upstart (Ubuntu):
status:	Confirmed → In Progress

Revision history for this message

Scott James Remnant (Canonical) (canonical-scott) wrote on 2009-06-18:

Aha!

And that flash of inspiration, plus a fresh look, made me realise that sysvinit only does ioctl(TIOCSCTTY) for the sysinit process - it doesn't do it for any usual runlevel change ones.

So Upstart is just fine here

Changed in upstart:
status:	Confirmed → Won't Fix

Revision history for this message

Launchpad Janitor (janitor) wrote on 2009-06-18:

This bug was fixed in the package upstart - 0.3.10-2

---------------
upstart (0.3.10-2) karmic; urgency=low

  * debian/upstart.postinst: Use telinit u to re-exec, rather than
    kill just in case it's not Upstart that's running. LP: #92177.
  * debian/event.d/system-services/tty*: Run getty in 8-bit clean
    mode. LP: #273189.
  * debian/event.d/upstart-compat-sysv/rc-default:
    - Don't use grep -w, instead split on $IFS and iterate. LP: #385911.
    - Check for any valid runlevel, not just S. LP: #85014.
    - Make console owner, since it may spawn sulogin.
  * debian/event.d/upstart-compat-sysv/rcS:
    - Spawn sulogin if given -b or "emergency". LP: #193810.
  * debian/event.d/upstart-compat-sysv/rcS:
    - Make console owner. LP: #211402.
  * debian/event.d/upstart-compat-sysv/rcS-sulogin:
    - Place the telinit code in post-stop, checking $UPSTART_EVENT first so
      we don't change the runlevel if we were stopped due to a runlevel
      change. LP: #66002.