From owner-freebsd-ports@FreeBSD.ORG Thu Oct 27 16:00:24 2011 Return-Path: Delivered-To: ports@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3B8C21065674; Thu, 27 Oct 2011 16:00:24 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) by mx1.freebsd.org (Postfix) with ESMTP id BA24B8FC15; Thu, 27 Oct 2011 16:00:23 +0000 (UTC) Received: from elsa.codelab.cz (localhost [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id 3D04228430; Thu, 27 Oct 2011 17:44:04 +0200 (CEST) Received: from [192.168.1.2] (ip-86-49-61-235.net.upcbroadband.cz [86.49.61.235]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id 18F0D28428; Thu, 27 Oct 2011 17:44:03 +0200 (CEST) Message-ID: <4EA97C42.1050806@quip.cz> Date: Thu, 27 Oct 2011 17:44:02 +0200 From: Miroslav Lachman <000.fbsd@quip.cz> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1.19) Gecko/20110420 Lightning/1.0b1 SeaMonkey/2.0.14 MIME-Version: 1.0 To: Wesley Shields References: <20111027091500.GM63910@hoeg.nl> <20111027130458.GD2934@atarininja.org> In-Reply-To: <20111027130458.GD2934@atarininja.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ports@FreeBSD.org, Ed Schouten Subject: Re: ports/162049: The Ports tree lacks a framework to restart services X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2011 16:00:24 -0000 Wesley Shields wrote: > On Thu, Oct 27, 2011 at 11:15:00AM +0200, Ed Schouten wrote: >> Hi folks, >> >> As crees@ suggested, I'm sending an email to ports@ about this. >> >> What really bothers me when I use the FreeBSD Ports tree on one of my >> systems, is that the behaviour of dealing with services is quite >> inconsistent. As mentioned in the PR: > > I agree inconsistency is a problem that could be addressed, but I don't > particularly agree with some of your statements. > >> - If I upgrade Apache, MySQL or PostgreSQL, it does not restart the >> service, meaning it won't use the freshly installed daemon. This has >> potential security issues. > > I'd prefer that no services are started or stopped automatically, unless > absolutely necessary for the upgrade. > >> - If I upgrade Dovecot, it shuts it down during the upgrade, but won't >> restart it. This means that I have to watch portmaster to complete and >> must not forget to restart Dovecot afterwards. Also Smartd from SmartMonTools and MySQL are stopped during upgrade process. - There are some ports touching user modified files on install / uninstall. For example some Apache modules are touching httpd.conf which is not good in some cases. If I upgrade mod_bw or mod_proctitle, it removes (comment out) the LoadModule line on uninstall phase and not enable it again on install phase of new version. So I must manually edit httpd.conf after each upgrade before Apache restart. > Unless it is absolutely necessary to stop and restart dovecot during an > upgrade I would like to see this removed. I think the main problem is that there is no difference between Uninstall and Upgrade (from ports perspective). It can be OK to shutdown daemon on uninstall. But somebody wants to restart services on upgrade and somebody wants to keep them running. Both have pros and cons. As mentioned above with Apache modules case, if there will be way to distinguish between uninstall and upgrade, then there will be ways to handle this problems more carefully. But intil then I vote for removing all custom "stop" / "restart" / "edit files" on per port basis - because it is inconsistent and unpredictable. >> My question is whether anyone has ever attempted to improve the >> integration with rc-scripts? In the PR I propose something along these >> lines: >> >> We know exactly which ports install rc scripts (USE_RC_SUBR). >> Why not run `/usr/local/etc/rc.d/${FOO} status' and >> `/usr/local/etc/rc.d/${FOO} stop' prior to installation. Based >> on the return value of the first, we can run >> `/usr/local/etc/rc.d/${FOO} start' after installation. > > I'm of the opinion that ports/packages should not touch running services > unless absolutely necessary. I think that the best would be to do some user configurable hooks on install / uninstall / upgrade actions in similar way as portupgrade does it. (e.g. somebody may want to stop another service before upgrade [restart] of mysql-server) Miroslav Lachman