Can start, but not restart, a stopped Upstart job

Bug #430883 reported by Anders Kaseorg on 2009-09-16
32
This bug affects 5 people
Affects Status Importance Assigned to Milestone
debhelper (Ubuntu)
Low
Steve Langasek
upstart (Ubuntu)
Low
Steve Langasek

Bug Description

Binary package hint: upstart

I would expect ‘restart’ to behave as ‘start’ if the job is not already running, just like with old init.d scripts. However, it fails with a strange error:

root@balanced-tree:~# stop network-manager
network-manager stop/waiting
root@balanced-tree:~# restart network-manager
restart: Unknown instance:
root@balanced-tree:~# start network-manager
network-manager start/running, process 11551

This makes it difficult to transition a package with an Upstart job from ‘dh_installinit’ to ‘dh_installinit --restart-after-upgrade’ (e.g. bug #430878), because the old prerm still stops the job and the new postinst fails to restart it.

Related branches

This is by design.

Upstart's "restart" command is intended to *only* atomically restart a running instance, that's because I consider it a bug that a restarting a service that is not running can start it in the old system.

This can mean that a sysadmin's desire to have a service not running is not honoured, and after an upgrade, have it started again without their consent.

Also note that in Upstart, "restart" *will not* reload the /etc/init/*.conf file - so any changes are not honoured. You have to fully stop and start the service (e.g. across a normal upgrade) to have changes in the conf file respected.

Changed in upstart (Ubuntu):
status: New → Won't Fix

We should review the debhelper autoscripts to make sure they're consistent with what packages expect.

Changed in debhelper (Ubuntu):
importance: Undecided → Medium
status: New → Confirmed

 tag ubuntu-boot
--
Scott James Remnant
<email address hidden>

Changed in debhelper (Ubuntu):
assignee: nobody → Scott James Remnant (scott)
importance: Medium → Low
Changed in upstart (Ubuntu):
milestone: none → ubuntu-8.04.4
milestone: ubuntu-8.04.4 → ubuntu-9.10-beta
Changed in debhelper (Ubuntu):
milestone: none → ubuntu-9.10-beta
Changed in upstart (Ubuntu):
milestone: ubuntu-9.10-beta → none
Changed in debhelper (Ubuntu):
assignee: Scott James Remnant (scott) → nobody
milestone: ubuntu-9.10-beta → none
assignee: nobody → Scott James Remnant (scott)
tags: removed: ubuntu-boot

Steve worked on making upstart-job more policy compliant, I think that he's done now.

Changed in debhelper (Ubuntu):
assignee: Scott James Remnant (scott) → Steve Langasek (vorlon)
Steve Langasek (vorlon) wrote :

Had a closer look at policy, and see that it says:

     `restart'
          stop and restart the service if it's already running, otherwise
          start the service

So upstart-job needs to be changed to implement this behavior still. I'll have a look at this ASAP.

Changed in upstart (Ubuntu):
assignee: nobody → Steve Langasek (vorlon)
importance: Undecided → Low
status: Won't Fix → Triaged
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package upstart - 0.6.3-6

---------------
upstart (0.6.3-6) karmic; urgency=low

  * Don't use "telinit q" to reconnect to D-Bus, since that breaks
    lots of things. Invent another secret way instead.

  [ Steve Langasek ]
  * upstart-job's restart target must also not fail when the service is not
    yet started. LP: #430883.

 -- Scott James Remnant <email address hidden> Thu, 01 Oct 2009 15:26:19 +0100

Changed in upstart (Ubuntu):
status: Triaged → Fix Released
Steve Langasek (vorlon) wrote :

debhelper side should be fixed in 7.3.15ubuntu3. Changelog:

debhelper (7.3.15ubuntu3) karmic; urgency=low

  * dh_installinit:
    - Create the upstart-job symlink even when --upstart-only is called,
      since this simplifies implementation of...
    - --restart-after-upgrade: we can't use the upstart 'restart' command here
      because this will give wrong behavior if we're adding a new job to an
      existing package; instead just use the standard invoke-rc.d snippet,
      which (combined with the above) will at least give us compatibility
      with policy-rc.d for preventing stopped jobs from starting on upgrade.
      (N.B.: prerm scripts could also safely reuse the invoke-rc.d handling
      instead of calling 'stop' directly, but leaving this alone for now
      because the current behavior is only minorly buggy.)
    - Drop unnecessary UPSTART_ONLY check; --upstart-only should never be set
      without having an upstart job so this is redundant.
    - postinst-reboot-required is never the right snippet to include here.
    - Merge in the final changes to the upstartification as accepted into
      debhelper upstream, dropping the --onlyscripts-upstart option from
      the documentation but mapping it to --onlyscripts for compatibility in
      karmic.
  * autoscript/postinst-upstart: typo fix.

Changed in debhelper (Ubuntu):
status: Confirmed → Fix Released
carloslp (carloslp) wrote :

I am using karmic up-to-date (upstart-0.6.3-11 and debhelper-7.3.15ubuntu3) and still broken. There is no way to stop/start a service:

root@quimerix:~# status networking
networking stop/waiting
root@quimerix:~# start networking
networking stop/waiting
root@quimerix:~# stop networking
stop: Unknown instance:
root@quimerix:~# stop networking
stop: Unknown instance:
root@quimerix:~# start networking
networking stop/waiting

?????????

And the old but working /etc/init.d says

root@quimerix:~# /etc/init.d/networking start
Rather than invoking init scripts through /etc/init.d, use the service(8)
utility, e.g. service networking start

Since the script you are attempting to invoke has been converted to an
Upstart job, you may also use the start(8) utility, e.g. start networking
networking stop/waiting

So explain me how its supossed that i can restart a service?

Steve Langasek (vorlon) wrote :

Not all upstart jobs correspond to running services. 'networking' is one that does not. 'stop/waiting' is the expected state for a task that has run, and finished.

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

Duplicates of this bug

Other bug subscribers