From owner-freebsd-current@FreeBSD.ORG Sun Feb 23 18:39:34 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7F7DF652 for ; Sun, 23 Feb 2014 18:39:34 +0000 (UTC) Received: from mail.lifanov.com (mail.lifanov.com [206.125.175.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 62B7D18A6 for ; Sun, 23 Feb 2014 18:39:34 +0000 (UTC) Received: by mail.lifanov.com (Postfix, from userid 58) id 2CD261A8AA1; Sun, 23 Feb 2014 13:39:28 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on mail.lifanov.com X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,SHORTCIRCUIT shortcircuit=ham autolearn=disabled version=3.3.2 Received: from app.lifanov.com (chat.lifanov.com [206.125.175.13]) by mail.lifanov.com (Postfix) with ESMTPA id 5ED121A8A9E for ; Sun, 23 Feb 2014 13:39:23 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Sun, 23 Feb 2014 13:39:23 -0500 From: Nikolai Lifanov To: freebsd-current@freebsd.org Subject: Re: libinit idea In-Reply-To: <0DB376E3-8C7F-4F20-9DEE-4DB98C078571@FreeBSD.org> References: <62A9DF47-C938-464B-92B6-9A2A96B5A9C9@FreeBSD.org> <530A39BB.6070003@allanjude.com> <0DB376E3-8C7F-4F20-9DEE-4DB98C078571@FreeBSD.org> Message-ID: <6d0ef0394dedb04335d4f61fb2b55f7f@mail.lifanov.com> X-Sender: lifanov@mail.lifanov.com User-Agent: Roundcube Webmail/0.9.5 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Feb 2014 18:39:34 -0000 On 2014-02-23 13:17, David Chisnall wrote: > On 23 Feb 2014, at 18:11, Allan Jude wrote: > >> sysrc solves this nicely, it is in base now, and is great for >> programmatically adding, removing and changing lines in rc.conf style >> files. It is also in ports for older versions of FreeBSD where it is >> not >> in base. > > The problem is, there is no such thing as an rc.conf style file. > rc.conf is just a shell script. If you only edit it with sysrc, or > you are careful to preserve the structure, then it's fine. There is > absolutely nothing stopping you, however, from writing arbitrarily > complex shell scripts inside rc.conf. Sure, it's a terrible idea to > do so, but when has that ever stopped anyone? > > An rc-replacement could enforce this by only accepting purely > declarative files for configuration, guaranteeing that if they were > syntactically valid they would also be machine editable, no matter > what the user does to them. > > David > Just my $0.02: I don't believe our current RC is broken. It's faster than most, it supports an early-late divider, virtual targets (NETWORK, etc.), dependencies, etc. Rewriting scripts (units) in C has a non-trivial cost to customization for end users. I have custom, packaged, RC scripts in /usr/local that are pretty easy to add and maintain. Shell script logic can go there and not in rc.conf proper. The rcorder program provides a pretty good idea for when these can be run, and, as already pointed out, sysrc can be used to add/remove/configure these on clusters of (automatically) managed machines. If all scripts a properly written, "service foo status" can also provide something that can be acted upon by configuration management systems. Serialization is great (libnv), but it's just gravy. The only feature I see that's missing is (SMF-style) service management, but for hardware events, like losing a network link or a disk, can be plugged in to devd configuration, also easily. Also, in real-life deployments, shutting down service dependencies is not practical either. For example, if postfix crashes, I don't want to stop postgey or dovecot. I just want to nanny postfix back up rather than trying to bring up the whole stack. Also, forking a shell does not have any significant cost to it when bringing up something like MySQL, since it's a small fraction of where the system spends its time to bring up a useful service. Rewriting scripts in C doesn't provide service management or give any on-demand (inetd, read: launchd) functionality. - Nikolai Lifanov