[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

stopping daemons in prerm/preinst (and info doc registration)



It is common for daemons to be stopped in pre{inst,rm}.  This makes
sense, but I wonder what the motivation is.

I see two possible explanations:

1.  Both postinst and prerm can often abstain from checking their
arguments.  prerm is called with any of:

  "remove [in-favour]"
  "[failed-]upgrade"
  "deconfigure"

Stopping a daemon in remove and deconfigure makes sense, and could
make sense for upgrades, too.  Is the intent to not provide a false
promise that the daemon will work during the upgrade, since the files
on disk may be in an inconsistent state?  (Eg. the daemon executable
has been updated to require a new file format, but that file hasn't
yet been updated, but the daemon forks+opens+parses that file for each
client).

2.  Package self containment.  If, hypothetically, a package had
multiple daemons (here, "daemon" means "initscript"), unconditionally
stopping all of them in prerm would avoid the need for preinst in
future revisions of the packages to stop those daemons, after
relevant checks of "$2".  This makes the package completely
"self-contained" WRT upgrades; future revisions don't need any cruft
to handle old upgrade paths (which would have to remain at least until
after the following stable release).

The alternative is to restart the daemon in postinst, and attempt to
provide no downtime; but, still the daemon isn't guaranteed to work
during the upgrade (ssh does this..).

I note that packages containing multiple initscripts are uncommon, but
this same thing also happens for info documents; debhelper presently
registers the document in postinst (makes sense) and deregisters it
in prerm, both the remove *and* upgrade paths.  This means that
there's a period during upgrades that the info document isn't
advertised, even though the file itself is guaranteed to exist (as
long as both new and old versions of the package include it).  The
advantage, again, is that new package revisions don't need preinst to
conditionally deregister the document.

Are these both considered important?

Please Cc: me.
Justin



Reply to: