From owner-freebsd-current@FreeBSD.ORG Sun Feb 23 19:09:39 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B510F43C for ; Sun, 23 Feb 2014 19:09:39 +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 8E5891AF5 for ; Sun, 23 Feb 2014 19:09:39 +0000 (UTC) Received: by mail.lifanov.com (Postfix, from userid 58) id 41BAE1A8AA6; Sun, 23 Feb 2014 14:09:39 -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 7D5BC1A8AA2 for ; Sun, 23 Feb 2014 14:09:38 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Sun, 23 Feb 2014 14:09:38 -0500 From: Nikolai Lifanov To: freebsd-current@freebsd.org Subject: Re: libinit idea In-Reply-To: <3F3C8E1C-C58C-4489-9762-ACA742B2A0C4@FreeBSD.org> References: <20140223182232.GA25967@lucius.XxX> <3F3C8E1C-C58C-4489-9762-ACA742B2A0C4@FreeBSD.org> Message-ID: <1084e79a6f6ff62ed3dca5ee0bcd45f3@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 19:09:39 -0000 On 2014-02-23 13:47, David Chisnall wrote: > On 23 Feb 2014, at 18:31, Freddie Cash wrote: > >> The main developer for systemd is very anti-portability and >> anti-!Linux. He >> had actively rejected patches that made his projects work on non-Linux >> systems. In order to port systemd to a non-Linux system, he wants you >> to >> first implement every Linux feature that systemd uses. >> >> systemd is a non-starter, and not with considering. > > I don't think that's a relevant discussion. The license would likely > preclude systemd from making it into the base system anyway. Please > let's not be too negative about the author of systemd: he's > responsible for more people switching from Linux to FreeBSD than any > other single individual I can think of and I would strongly encourage > him to continue. > I also noticed this. > The relevant question is whether it does anything in a way that is > sufficiently sensible to merit a FreeBSD service management > infrastructure doing it in the same (or a similar) way. > > Oh, two things missing from my original list: > > - Service jails should be able to run without an init process, with > just the required libraries installed and the host machine's init > system starting the jail and the service process(es) inside it. > Isn't this a bit too complicated? If there is an init script under $jail/usr/local/etc/rc.d, then the host init will need to find it, which can be even more complicated if rc search path in the jail is customized (prefixed if it's managed by a different department, for example). Host init will have to read the jail configuration, parse it too, and then manage children and pids of the jailed services, including reparenting, all within a jail context. Then the admin in that jail would need to be able to restart services, affecting host init, which opens a whole new can of worms. If init program is skinny and not too complicated, which it is, there is no tangible overhead. And if a jail really needs a single simple service, init process in the jail can *be* that, like jexec myjail /bin/sh -c somestuff (or even /usr/local/bin/myservice -c myservice conf). > - The init system should use process descriptors, not pids, for > tracking processes, preventing issues with pid reuse and so on (and > removing the need to write pid files). If process descriptors do not > provide the required functionality (e.g. the ability to trace forked > children) then this should be added. > This is a good idea. > David > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to > "freebsd-current-unsubscribe@freebsd.org"