Bug#904558: What should happen when maintscripts fail to restart a service
On Fri, Sep 21, 2018 at 10:07:31PM +0200, Tollef Fog Heen wrote:
> ]] Ian Jackson
>
> > Tollef Fog Heen writes ("Bug#904558: What should happen when maintscripts fail to restart a service"):
>
> [...]
>
> > > This means that failure to start a daemon should generally not cause the
> > > postinst to fail.
> >
> > ... I disagree with that. I think that in the usual case, if the
> > daemon is broken, and the package's purpose is to provide that daemon
> > service, then the package probably isn't providing its API.
>
> I don't think dpkg relationships are a good fit for expressing those
> kinds of statements. They are not about in-memory and process state
> management, they're about what's on disk.
The point here is that failure to restart the daemon is a *symptom* of
breakage of the *on-disk state*, so we're really arguing the same thing?
[...]
> > I disagree with this.
> >
> > dpkg dependencies are not just about what sets of packages can be
> > coinstalled. They also imply sequencing of package setup. And since
> > starting daemons is part of package setup, dpkg dependencies imply a
> > sequencing of daemon startup.
>
> If you include the word «attempted» there, I might agree. policy-rc.d
> for instance enters the picture here. Blacklisting in the init system
> does as well, probably others too. The landscape is pretty crowded with
> actors.
Nobody is arguing that if the init system or policy-rc.d block service
starts, that then postinst should silently not start the daemon.
However, in the absense of such things, if postinst fails to restart the
daemon, it knows something is wrong. "something is wrong" should not
happen after package upgrade; if it did, we failed. "failed" means
postinst should not exist successfully.
> > That is actually necessary in the case where the startup of daemon B
> > can only successfully completed if daemon A is up,
>
> That's the job of the init system's dependency resolution mechanisms,
> not dpkg's. dpkg does not have information about what is running and so
> can't do this. Ordering is also separate from dependencies, at least
> for some init systems.
Some init system dependency resolution mechanisms also only work
properly once all the packages involved have been configured, so that's
not a valid point.
--
Could you people please use IRC like normal people?!?
-- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008
Hacklab
Reply to: