From owner-freebsd-ports@freebsd.org Tue Jun 26 19:01:56 2018 Return-Path: Delivered-To: freebsd-ports@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C64C01011F53 for ; Tue, 26 Jun 2018 19:01:55 +0000 (UTC) (envelope-from SRS0=Ta0Z=JM=quip.cz=000.fbsd@elsa.codelab.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 531E27EA1B for ; Tue, 26 Jun 2018 19:01:55 +0000 (UTC) (envelope-from SRS0=Ta0Z=JM=quip.cz=000.fbsd@elsa.codelab.cz) Received: from elsa.codelab.cz (localhost [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id 075182840C; Tue, 26 Jun 2018 21:01:49 +0200 (CEST) Received: from illbsd.quip.test (ip-86-49-16-209.net.upcbroadband.cz [86.49.16.209]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id 2F3D928412; Tue, 26 Jun 2018 21:01:47 +0200 (CEST) Subject: Re: Should a package restart on upgrade itself To: Josh Paetzel , freebsd-ports@freebsd.org References: <595296BF.3040906@quip.cz> <77549bbc-50b1-7635-2ca4-1ae229098506@quip.cz> <1530036181.4184901.1421203184.0039ADE4@webmail.messagingengine.com> From: Miroslav Lachman <000.fbsd@quip.cz> Message-ID: <4edeee59-779c-46cc-0105-601c554bd7c8@quip.cz> Date: Tue, 26 Jun 2018 21:01:47 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Firefox/52.0 SeaMonkey/2.49.3 MIME-Version: 1.0 In-Reply-To: <1530036181.4184901.1421203184.0039ADE4@webmail.messagingengine.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2018 19:01:56 -0000 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@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-ports >> To unsubscribe, send any mail to "freebsd-ports-unsubscribe@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