From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 0380B138BF3 for ; Tue, 18 Feb 2014 09:47:57 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id EE589E0BF9; Tue, 18 Feb 2014 09:47:51 +0000 (UTC) Received: from mail-wg0-f52.google.com (mail-wg0-f52.google.com [74.125.82.52]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id BAC04E0BE0 for ; Tue, 18 Feb 2014 09:47:50 +0000 (UTC) Received: by mail-wg0-f52.google.com with SMTP id b13so3114435wgh.7 for ; Tue, 18 Feb 2014 01:47:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=81/CC3QBfYrQU2b4S5racMJOf0szwW6zFjoJV2Bf1hw=; b=HVbCcXO6EMYeOW6X+nhuQIzVbZ+h6SSFjpXIuvyE30Vk0JAs+cSO/DKnJGBhAcu/CV lznKK8AkTPNqSVbSNJgxUw7dIQsUE5uoGP35L5WBq57uNJgNWX8iXeF/M3naN3d27lFv svCo78jeHpoU1gs9gWAZbK2RHG3IJDubWaMz/gxMWc9IhqwX2dQCOhLqnFjc6cBXnmIs WmbeoVzNrVVFY1Hl+11r8CVUUMAdO5FE2roaNFYjwsSXbMf4/uApSeyuzQXtVdK2AwLJ ZS616xDt7ukQPI9XEHQ96Qb6veTNTcAfTNYcSd/9aw33kyACwTB1TQ3l9N4w4qBhjf6D GcXw== X-Received: by 10.194.60.37 with SMTP id e5mr21204505wjr.32.1392716869519; Tue, 18 Feb 2014 01:47:49 -0800 (PST) Received: from [10.1.20.200] (dustpuppy.is.co.za. [196.14.169.11]) by mx.google.com with ESMTPSA id h13sm43906788wjr.22.2014.02.18.01.47.48 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 18 Feb 2014 01:47:49 -0800 (PST) Message-ID: <53032C35.3060307@gmail.com> Date: Tue, 18 Feb 2014 11:47:33 +0200 From: Alan McKinnon User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] Debian just voted in systemd for default init system in jessie References: <52FF84CE.2050301@libertytrek.org> <52FF9D58.3000608@libertytrek.org> <201402152023.10543.michaelkintzios@gmail.com> <5300DD51.5060207@libertytrek.org> <5300EA3A.5020801@gmail.com> <24165346-F62B-4CD4-BB43-0D5A68BE0004@stellar.eclipse.co.uk> <530268AE.3050603@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Archives-Salt: c9a2d93d-2c67-4751-992b-10b1e8cd8ffe X-Archives-Hash: 2b8bd4fbde69fda2468ab9d8447097f7 On 18/02/2014 05:46, Mark David Dumlao wrote: > On Tue, Feb 18, 2014 at 3:53 AM, Alan McKinnon wrote: >> > On 17/02/2014 17:29, Stroller wrote: >>> >> >>> >> On Sun, 16 February 2014, at 4:41 pm, Alan McKinnon wrote: >>>> >>> ... >>>> >>> Whatever problems Red Hat are trying to solve in the Red Hat space are >>>> >>> problems that do not affect me, so I do not need Red Hat's solution. As >>>> >>> for Gnome, I have yet to see a valid reason why Gnome *must* use >>>> >>> systemd; that is simply not true at all. >>> >> >>> >> I thought this all boiled down to "trying to login to GDM using accessibility functions and a bluetooth hearing aid" (or bluetooth keyboard, for that matter). >> > >> > That was the classic rationale for "no separate /usr without an initrd" >> > in udev - the claimed need to have any arbitrary runnable code available >> > to be run before the entire system is up and running. >> > >> > Red Hat's reasons for pushing systemd are more fuzzy and nothing I've >> > read so far tells me we have the full picture. Two things seem highly >> > plausible: >> > >> > 1. An init system that can use modern features of the Linux kernel (most >> > often Linux-only at this point) like cgroups >> > 2. Extremely fast boot times to spin up virtual machines in a fraction >> > of the time it currently takes. >> > >> > #1 may or may not be desirable, I honestly don't know. What I have seen >> > is a lot of theory and not much reproducable fact. > init scripts, in general, are ad-hoc, quirky, and incomplete > implementations of service supervision in bash. They're reliable so > long as the daemon can be relied on to advertise one or all of its > processes in a pid file. Thing is, there are way too many different > possible setups for services for that to be the case. In the average > case watching a PID file works. And since most people use "average > software", most people don't care. That's ok. > > Thing is an init isn't just for "most people". It's for "all people". > It should be reliable for all services. > > I used to use cherokee. Fast, light, awesome, and with a web admin. > The init script always failed me. /etc/init.d/cherokee stop was not a > guaranteed stop to all forked cherokee processes - the parent pid > dies, but some forked process or something, usually related to > rrdtool, doesn't. Or the parent does exit and erases the pid file but > it returns control immediately and its not yet done exiting. Something > like that or other. Point is, I've several times had to ps aux|grep > ... kill; zap; start - on production servers. Valid point. Other than vixie-cron (damn thing just never seems to die properly on any platform so restarts always fail) I don't really run into these issues What I do run into is daemons that drop privs on start up, like tac_plus. Unwary new sysadmins always try start/stop it as root, causing an unholy mess. Root the owns the log and pid files, when tac_plus drops privs it can't record it's state so continues to service requests but fails to log any of them. For an auth daemon, that's a serious issue. -- Alan McKinnon alan.mckinnon@gmail.com