Ticket #567 (closed defect: wontfix)

Opened 14 years ago

Last modified 12 years ago

upstart is too cool for invoke-rc.d

Reported by: broder Owned by:
Priority: normal Milestone: The Distant Future
Component: -- Keywords:
Cc: Fixed in version:
Upstream bug:  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=591791


Now that a bunch of stuff has been upstart-ified (is that the word?), invoke-rc.d $JOB reload doesn't work anymore.

I think this means that we should do something like

if [ -e /etc/init/gdm.conf ]; then
    reload gdm
elif hash invoke-rc.d >/dev/null 2>&1; then
    invoke-rc.d gdm reload
    /etc/init.d/gdm reload

Otherwise nothing kicks gdm.

Change History

comment:1 Changed 14 years ago by lizdenys

  • Owner set to lizdenys
  • Status changed from new to accepted

comment:2 Changed 14 years ago by jdreed

Googling suggests that, yes, you need to add a third clause for upstart jobs. If there is a useful mailing list for discussing Debian Policy, it might be useful to ask how upstart fits in with  http://www.debian.org/doc/debian-policy/ch-opersys.html#s9.3.3.2

comment:3 Changed 14 years ago by jdreed

I see that this has screwed people building livecds and using pbuilder ( LP:523688). The answer seems to be "divert initctl". Whenever someone suggests that upstart grow a feature like policy-rc.d, the answer seems to be a deafening chorus of crickets. So we should probably go ahead and work around this for now.

comment:4 Changed 14 years ago by jdreed

Discussion on zephyr suggests we can do:

if [ -e /etc/init/gdm.conf ]; then
       if [ -x /usr/sbin/policy-rc.d ]; then                                    
         policy-rc.d gdm && reload gdm                                   
         reload gdm                           
elif hash invoke-rc.d >/dev/null 2>&1; then
    invoke-rc.d gdm reload
    /etc/init.d/gdm reload

Or we should possibly be doing something with invoke-rc.d --query

comment:5 Changed 13 years ago by broder

  • Upstream bug set to http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=591791

My understanding from talking with Steve Langasek at UDS this fall was that invoke-rc.d was supposed to backend into service(1), which in turn knows about both Upstart and sysvinit jobs. This doesn't actually seem to be the case, though, so somebody should probably file bugs against the various packages involved.

It's possible that he was confused about actual Upstart support vs. Upstart jobs which also have compatibility sysvinit jobs (c.f. /etc/init.d/gdm -> /lib/init/upstart-job on a Upstart-ified system).

Although, now that I think about it, I'm not entirely clear why just calling invoke-rc.d and running through the compatibility layer wouldn't work.

comment:6 Changed 13 years ago by jdreed

So, I'm confused here, because AFAICT, all Upstart jobs ship sysvinit compatibility scripts, which invoke-rc.d will run just fine. It is true that "invoke-rc.d gdm reload" does nothing, however I'll note that "reload gdm" also does nothing. "invoke-rc.d gdm restart", however, works just fine (and has the expected result). So, uh, is the bug here that "reload" stopped doing anything useful in new-gdm?

comment:7 Changed 13 years ago by jdreed

  • Owner lizdenys deleted
  • Status changed from accepted to new
  • Milestone changed from Natty Alpha to The Distant Future

I'm tempted to WONTFIX this, unless someone gives me an example that doesn't involved gdm.

comment:8 Changed 12 years ago by jdreed

  • Status changed from new to closed
  • Resolution set to wontfix

Re-open this with a reproducible test case if it's still an issue, but I'm fairly sure this was a red herring.

Note: See TracTickets for help on using tickets.