Despite how it may appear, I'm not doing this merely to be obnoxious. :(
On Wed, Nov 15, 2000 at 09:13:10AM -0200, Henrique M Holschuh wrote:
> As I said, they're there to avoid confusing the user. If they had no
> possible purpose I'd have removed them before invoke-rc.d ever seen the
> light of this list :-)
I guess I'm not seeing what's confusing about it. If invoke-rc.d is meant
to fallback to restart-if-running, that's what the user should expect
when invoke-rc.d is called. If they're doing `apt-get install portmap',
it seems reasonable for them to (a) expect portmap to be restarted, and
(b) not to really care exactly how that happens.
> > Don't remove them, just make them conditional on a --verbose option.
> I would, but I want them there in the default case. The idea of fallbacks is
> not even remotely common (it's not difficult, but nobody else does it), so I
Maybe there's a reason nobody else does it :)
> Without the restart-if-running fallback, invoke-rc.d simply says:
> invoke-rc.d: initscript action "restart" not executed.
I don't think it should even say that. (Well, unless someone's using
--verbose)
Stepping back a bit, here's what I see happening. When invoke-rc.d actually
does something, output like the following (exactly what happens now):
] [aj@blae ~]$ ps ax | grep [p]ortmap
] 169 ? SW 0:00 [portmap]
] [aj@blae ~]$ sudo dpkg -i /var/cache/apt/archives/portmap_5-1_i386.deb
] (Reading database ... 65109 files and directories currently installed.)
] Preparing to replace portmap 5-1 (using .../archives/portmap_5-1_i386.deb) ...
] Stopping portmap daemon: portmap.
] Unpacking replacement portmap ...
] Setting up portmap (5-1) ...
] Starting portmap daemon: portmap.
] Restoring old RPC service information...done.
] [aj@blae ~]$ ps ax | grep [p]ortmap
] 5764 ? S 0:00 /sbin/portmap
and when it doesn't run stuff (because you're in single user mode,
or whatever):
] [aj@blae ~]$ ps ax | grep [p]ortmap
] [aj@blae ~]$ sudo dpkg -i /var/cache/apt/archives/portmap_5-1_i386.deb
] (Reading database ... 65109 files and directories currently installed.)
] Preparing to replace portmap 5-1 (using .../archives/portmap_5-1_i386.deb) ...
] Unpacking replacement portmap ...
] Setting up portmap (5-1) ...
] [aj@blae ~]$ ps ax | grep [p]ortmap
Which is acheived by having invoke-rc.d output nothing unless something
actually bad happens (/etc/init.d/portmap doesn't exist, say), rather
than just having it happen to fallback to restart-if-running, or whatever
it might do.
I don't have a problem with the concept of falling back to
`restart-if-running', I just don't like the way it invokes undefined
behaviour in existing scripts in (relatively) normal use.
> Which is what 99.99% of the Debian systems will ever generate. People using
> policy-rc.d will probably want the more informative messages "on" by default
See, I don't agree here at all. I think people'll rather have it all
just work, and not feel a need to be reassured of it everytime they do
an upgrade. Have some faith in your code already :)
> > > > invoke-rc.d foo restart
> > > > for scripts that do support r-i-r, use:
> > > > invoke-rc.d foo restart-if-running
> By itself, there's nothing wrong with restart. However:
> * restart out-of-runlevel is now denied (does nothing) by invoke-rc.d.
> If a maintainer script wants to make sure a running daemon is stopped and
> restarted (which is why 90% of the maintainer scripts would use a restart),
> it MUST use either "stop; start" or "restart-if-running" instead of
> "restart", or else the service will not even be stopped.
Sure. And that's annoying, but it's not completely out of left field. Your
failure case is when the admin's in single user mode, manually started
a daemon that's not usually running in that runlevel, and upgrading
a package that normally restarts that daemon, but which hasn't been
updated since the daemon's package had a restart-if-running option added;
and your failure is just that the daemon doesn't get restarted to take
notice of the new/updated package.
It's a bug, sure, but I don't think it's one we really need to stress over
(ie, "should" and normal severity seem quite enough). Especially since the
only packages this is likely to affect are presumably paying pretty close
attention to the package adding restart-if-running (dict-* and dictd, eg).
> Also, given the fact that the only way a maintainer responsible by the
> service-providing package can signal he does NOT want his daemon running
> afoul out-of-runlevel is to add 'restart-if-running', 'restart' now has to
> be severely deprecated if 'restart-if-running' is added.
Again, I don't see the need for the vehemence in the deprecation. Seems
like it'd just naturally be used asap because it's *better*.
> OR, we can have invoke-rc.d fallback to 'restart-if-running' for a
> 'restart'. This have the same effects that the above has. There's no need to
> do both, but one of the two should be done.
It doesn't have exactly the same effects, as noted previously. They're
different solutions, with different results.
> > Look, all I'm saying is that having a bunch of error messages appear in
> > the usual case is a bad implementation choice, not that it's illegal or
> > against policy or whatever.
> I understood that. I was only pointing it out that many people think that
> such messages are acceptable,
Not from postinst scripts, that's why people have >/dev/null for
update-rc.d all the time; and why people bitch about tex and emacs
upgrades (well, one of the reasons...).
> A few minutes of thought in the issue tells me that I should leave things as
> is (i.e.: do not start stuff in runlevel S unless they're meant for runlevel
> S). It seems that you agree with me.
Yup. I think that's the sensible thing to do.
> Please review the changelog and new policy diff and second them when they
> arrive in the BTS (just to make sure it doesn't look like you seconded
> something and then I changed it under your foot).
Pfft. I may disagree with you how to do it, but I don't think you're
dishonest or anything.
Cheers,
aj
--
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG signed mail preferred.
``We reject: kings, presidents, and voting.
We believe in: rough consensus and working code.''
-- Dave Clark
Attachment:
pgpl3_ZuGlDkQ.pgp
Description: PGP signature