Should a package restart on upgrade itself

[Miroslav Lachman]

Josh Paetzel wrote on 2018/06/26 20:03:
> 
> 
> On Tue, Jun 26, 2018, at 6:27 AM, Miroslav Lachman wrote:
>> Miroslav Lachman wrote on 2017/06/27 19:32:
>>> Matthias Fechner wrote on 2017/06/27 18:29:
>>>> Dear all,
>>>>
>>>> it is always a pain if pkg upgrade a lot of packages to restart all
>>>> services to make sure update/security fixes are applied to all running
>>>> services.
>>>>
>>>> Is there an option in pkg that it restart services automatically or is
>>>> it OK if I would add a post-install script to the packages (I maintain)
>>>> that will include a "service foo restart"?
>>>>
>>>> What is best practice here?
>>>
>>> Please don't do this.
>>> Some ports did this in the past and this was really a pain during larger
>>> upgrades. It sometimes leave services stopped (hi MySQL).
>>>
>>> The same bad practice is disabling / enabling Apache modules on upgrade.
>>>
>>> pkg upgrade should just do it's work - upgrade packages on disk. But
>>> manipulating config files and restart of services is up to me - the
>>> Administrator (or my tools).
>>>
>>> It would be nice to have some kind of "hooks" in pkg, which can be used
>>> to notify deployment tools that some services should be (re)started, or
>>> do restart in some simpler environment if user allows this (setup hooks
>>> for service restart).
>>> But is must not be done automatically for individual ports / packages
>>> even if maintainer thinks it is Good Idea (tm)
>>
>> Again and again and again...
>>
>> Can we have some written (or do we have?) policy to not
>> stop/start/restart services from some @preunexec / @postexec targets?
>> I really don't like that some packages are still shutting down or trying
>> to restart in the middle of the pkg upgrade process.
>>
>> One example from today upgrade:
>>
>> [87/96] Extracting open-vm-tools-nox11-10.2.5,2: .......... done
>> Stopping vmware_guestd.
>> Waiting for PIDS: 516.
>> Loading vmmemctl kernel module: already loaded.
>> vmware_guestd not running? (check /var/run/vmware_guestd.pid).
>> Starting vmware_guestd.
>>
>> Can committers take care of this bad behaviour and not commit things
>> like this?
>> https://svnweb.freebsd.org/ports/head/emulators/open-vm-tools/pkg-plist?revision=457485&view=markup
>>
>> @preunexec %%PREFIX%%/bin/vmware-rpctool 'tools.set.version 0' ; service
>> vmware-guestd stop 2>/dev/null || /usr/bin/true
>> @postexec service vmware-kmod restart && service vmware-guestd restart
>> || /usr/bin/true
>>
>> Kind regards
>> Miroslav Lachman
>> _______________________________________________
>> freebsd-ports at freebsd.org mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-ports
>> To unsubscribe, send any mail to "freebsd-ports-unsubscribe at freebsd.org"
> 
> Here's the diff for the commit you referenced:
> 
> https://svnweb.freebsd.org/ports/head/emulators/open-vm-tools/pkg-plist?r1=457023&r2=457485&pathrev=457485
> 
> Which part are you objecting to?
> 
> I don't really have any objections to changing open-vm-tools.  I'll note that I inherited it in it's current state with regards to defaults and restarting, an it's probably worth fining out why it does those things before blatantly changing things.
> 
> It's possible that open-vm-tools is a poor example of what you are talking about based on it providing services for the OS for running on VMWare versus running some application service or daemon , but I will have to think about this before taking a strongly held opinion.

I am sorry, I was not talking about that revision. Only about @preunexec 
and @postexec. They were added in
https://svnweb.freebsd.org/ports/head/emulators/open-vm-tools/pkg-plist?r1=388693&r2=436703
https://svnweb.freebsd.org/ports/head/emulators/open-vm-tools/pkg-plist?r1=436816&r2=444773

Stopping / Restarting any service in the midle of running pkg upgrade is 
Bad Thing (in my point of view).
Note that "service vmware-kmod restart" is not doing what somebody may 
think it is - you end up with new version of vmware-guestd and old 
version of loaded kernel module, because it is not unloaded (and in 
situations like securelevel cannot be even loaded)

Kind regards
Miroslav Lachman