(re)starting of a daemon after package update

[Panu Matilainen]

On 06/20/2012 06:59 PM, Reindl Harald wrote:
>
>
> Am 20.06.2012 17:42, schrieb Panu Matilainen:
>> On 06/20/2012 03:37 PM, Reindl Harald wrote:
>>>
>>>
>>> Am 20.06.2012 14:32, schrieb Björn Persson:
>>>> Michal Hlavinka wrote:
>>>>> Correct approach would be to save state before installation of new
>>>>> version starts and start dovecot (if flag is set) after old version is
>>>>> removed - that would mean %postun script. This does not seem to work on
>>>>> reinstall (the same version is installed) - %postun script is not executed.
>>>>
>>>> Please also consider what happens when the new version of Dovecot requires a
>>>> new version of some library. RPM will ensure that both packages are updated in
>>>> the same transaction, but if I understand correctly it's not until %posttrans
>>>> that you can be sure that the new library is in place.
>>>
>>> one reason more why the cuurent behavior re-starting services
>>> on updates is simply wrong:
>>
>> It's also not true.
>>
>> If new dovecot requires new version of libfoo, that new libfoo with all its files
>> is guaranteed [*] to be installed before the new dovecot, ditto for all their
>> dependencies recursively. Reverse for the erasure phase, eg the older
>> libfoo version is only removed after everything depending on it has been removed.
>
> boah and if it does NOT require a new version because it is
> not a new version of a library since new releae-version
> with patches is not uncommon and if one of the patches
> is security relevant there is NO gurantee that the service
> itslef would not be restarted BEFORE the pacth is applied

Rpm always orders by dependencies within a transaction, so if library 
and the service depending on the library are updated in the same 
transaction the library will be updated first.

>> If you think about it a little, not a single upgrade involving soname bumps and
>> the like would work properly if it wasn't like that
>
> i do not need to think
>
> i was there, i saw was happened on dist-upgrades, i fixed them
>
> i saw a dist-upgrade on the fist-testmachine restart httpd
> which failed for some reason and AFTER some time you could
> start httpd again
>
> * i rebuilt the httpd package
> * i removed the dumb restart from the SPEC file
> * i rolled out the dist-upgrade on 20 production machines
> * no second downtime of httpd except the usual reboot
>
> don't get me wrong, but i am not interested in theory
> i am intersted in stable update-processes whch were painless
> years ago and now can only be achievd be rebuilt a lot of pakcages

"Some reason" can't be analyzed... but like said, there certainly are 
all sorts of gaps and holes where things can be temporarily broken while 
a transaction is running, including file-renames, old files from 
previous version still being around, dependencies (such as service 
inter-dependencies) which rpm does not know about, dlopen()'ed libraries 
etc. Most of the time things work well enough that nobody notices, but 
an assumption that the system stays in a fully consistent state 
throughout an online update is simply bogus, service restarts or not.

	- Panu -