From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <gentoo-dev+bounces-53915-garchives=archives.gentoo.org@lists.gentoo.org>
Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80])
by finch.gentoo.org (Postfix) with ESMTP id 838CD13800E
for <garchives@archives.gentoo.org>; Thu, 9 Aug 2012 15:27:00 +0000 (UTC)
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
by pigeon.gentoo.org (Postfix) with SMTP id 39F27E0603;
Thu, 9 Aug 2012 15:26:45 +0000 (UTC)
Received: from mail-bk0-f53.google.com (mail-bk0-f53.google.com [209.85.214.53])
by pigeon.gentoo.org (Postfix) with ESMTP id 8DA5BE0477
for <gentoo-dev@lists.gentoo.org>; Thu, 9 Aug 2012 15:25:50 +0000 (UTC)
Received: by bkwj4 with SMTP id j4so266574bkw.40
for <gentoo-dev@lists.gentoo.org>; Thu, 09 Aug 2012 08:25:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20120113;
h=mime-version:sender:in-reply-to:references:date
:x-google-sender-auth:message-id:subject:from:to:content-type;
bh=AKs8daTrtIYVqSnJlgu6hodic8ekIX47WDixXVxw0qE=;
b=RyAnJy9MjfGTpFc+52X9D2DWvD1xSFBdvhiCLpRzYwjirMOC+wfisZk69ZNLK16luE
BAu6LlNR3GGKluU5QsqYCp1a35Y3RZJ20GJztLDxx9supDlqP7LY8WX/rNbHGcdNBJWf
2SIK98plgiRekCVcAkDwfNBEJZGkRy7Y7MIT7cgFcr0X4Cs7+1sZsGljVnSB7Pnr0JGc
+QKDorF7JY2TpunerhXBxNVGCNPZKYW+zvWCAg1qM+YzL2j+QJiwprB7mEnZGBMIuVE8
J7gAxCOv1hb+q7Csmu47xUf3LLbl2is8TsoAEVgEJ9ZbruMmxbZHJi8NInzeC5uGszc4
i8kA==
Precedence: bulk
List-Post: <mailto:gentoo-dev@lists.gentoo.org>
List-Help: <mailto:gentoo-dev+help@lists.gentoo.org>
List-Unsubscribe: <mailto:gentoo-dev+unsubscribe@lists.gentoo.org>
List-Subscribe: <mailto:gentoo-dev+subscribe@lists.gentoo.org>
List-Id: Gentoo Linux mail <gentoo-dev.gentoo.org>
X-BeenThere: gentoo-dev@lists.gentoo.org
Reply-to: gentoo-dev@lists.gentoo.org
MIME-Version: 1.0
Received: by 10.204.129.8 with SMTP id m8mr2054344bks.62.1344525949455; Thu,
09 Aug 2012 08:25:49 -0700 (PDT)
Sender: freemanrich@gmail.com
Received: by 10.205.82.12 with HTTP; Thu, 9 Aug 2012 08:25:49 -0700 (PDT)
In-Reply-To: <20120809140228.18316.qmail@stuge.se>
References: <CACR_K2tKrkCBmsbBXen-Fqx3JYjpWq-qYGCHxEv6C4B9zh1t2Q@mail.gmail.com>
<1344366029.24762.31.camel@TesterTop4>
<502377E7.8010803@gentoo.org>
<20120809140228.18316.qmail@stuge.se>
Date: Thu, 9 Aug 2012 11:25:49 -0400
X-Google-Sender-Auth: PO4wcDXFfj7wxEDASbnPuYtQ3R8
Message-ID: <CAGfcS_maCht2j2DSEDCNCPYZufk0cTx1ahrYz30uFThst3EWbw@mail.gmail.com>
Subject: Re: [gentoo-dev] pid 1 design
From: Rich Freeman <rich0@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Content-Type: text/plain; charset=ISO-8859-1
X-Archives-Salt: 30fd2ae4-7e94-4bee-9d59-887c638d3972
X-Archives-Hash: 8b354cf288ad8f024bb448f22dbd4bc7
On Thu, Aug 9, 2012 at 10:02 AM, Peter Stuge <peter@stuge.se> wrote:
> Luca Barbato wrote:
>> Repeat after me: having your first process require anything more
>> than libc is stupid and dangerous.
>
> Why do you say?
>
> And why is libc different from other libraries, say libuuid or
> libext2fs? I mean: Why allow pid 1 to require libc, it could
> just be statically linked.
So, while I've had only positive (but limited) experiences with
systemd, I can understand the fundamental design concern with having a
complex process running as pid 1. If init dies, the kernel panics
(just boot your system with init=/bin/bash and type exit to see).
So, a simple init that is less likely to die is a good thing.
That said, init NEEDS to be able to communicate with other processes
if you don't want it to keep propping things up when you're trying to
shut the system down. This is usually done via signals (init can trap
them all at least on linux), but I believe there are other mechanisms
that have been used in traditional init implementations. It seems
like the big changes to systemd/etc are to allow it to communicate via
dbus.
I'm not sure why having systemd be a monolithic PID=1 solution was
chosen - that is probably a better topic for their lists. Maybe a
more resilient solution would be to have an init as PID=1 that does
nothing but launch systemd and keep it propped up until it gets a
signal from systemd. However, that could have issues I'm just not
thinking of. That could be accomplished just by running the
traditional init and having a runlevel with just systemd in it, aside
from any issues not being PID 1 creates for systemd.
Rich