Can start, but not restart, a stopped Upstart job

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.

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

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

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

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.

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

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.

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?

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.