Re-starting daemons across upgrades?

[Matthias Andree]

Am 28.09.2011 22:40, schrieb Łukasz Wąsikowski:
> W dniu 2011-09-28 20:53, Matthias Andree pisze:
> 
>>> We shouldn't go that way at all. Restarting service right after it's
>>> update is not a good thing. In many cases service will not start,
>>> because of needed configuration changes od other ports not recompiled or
>>> updated. The safe way is to not stop service at all. Let the system
>>> operator restart service manually when he finish all the needed update
>>> tasks.
>>
>> Well, the maintainer should know if the service can be restarted or
>> needs manual intervention. For patch level upgrades - pathological cases
>> like OpenLDAP or Cyrus-SASL interactions aside - you normally can
>> restart the service without further ado.
> 
> That's true. Still, I often like to update software during the work
> hours and restart it in the middle of the night. It's not as annoying to
> customers as restarting critical service during peak hours. Restart time
> should be left for operator to decide.

So basically, we need a lever the operator can flip, and that typical
ports running daemons, respect - that can state whether ports
auto-restart deamons previously running (which would entail complaining
the if needs manual intervention, like chasing configuration language
changes, or other), or whether not to and just collect their names and
list them so the operator can do it at a convenient time -- assuming the
daemons are up to that task (continue running).

On the other hand, one might wonder if in such cases it's not better to
pre-build the required updated packages in Tinderbox, and install them
as binary package at a convenient time later.

My line of reasoning is that "live" updates (meaning replacing ANY parts
of the system) probably aren't a good idea if there's a nontrivial
number of ports to rebuild, unless you have a full set of old packages
backed up (to roll back quickly if something goes amiss in the upgrade)
and new ones pre-built but not yet installed (to roll forward quickly
without the need to wait for - possibly failing - builds).