From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.77) (envelope-from ) id 1SoLs8-0005H0-An for garchives@archives.gentoo.org; Mon, 09 Jul 2012 21:52:00 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 6C062E077F for ; Mon, 9 Jul 2012 21:51:59 +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 03C49E01C5 for ; Mon, 9 Jul 2012 18:35:49 +0000 (UTC) Received: by bkwj4 with SMTP id j4so4808250bkw.40 for ; Mon, 09 Jul 2012 11:35: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=iXMmEqbKNQhglpM3vKO9Z3OhwQpsusCPRP2YnFkv6nc=; b=MtEN2Me8NlEFQLDjzJH+QUBv/1/BKAjE28f/3SVWkk3cX5oIjd11X/6d30f3Stw0yB 1+LobSMMbsZsM4i7LLusfCAJj2rRg/Me49R2t75wRgKsd1DxGbs001Xu3JL9f/Mw+ERJ 02tNoltKelO5oiJSsXEKiPSkRSKK9nfmj2+H7k3J6uZ4b2hBaVhATdd+O7HOMY6FAYuu HVC6z1o9x1HBn7XV0p3yGNVeRfYRV7s7jKj/RVDHOxJY+f9OqbqHnYOU12Y1QLwSzGD0 EKzmE/fdeev9RbRbp2S1ZNDsAU8qfL6//YjMfVTIlZoRMzDBF+PwlLRYZOR0lc3/TpbZ sNbQ== Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-soc@lists.gentoo.org Reply-to: gentoo-soc@lists.gentoo.org MIME-Version: 1.0 Received: by 10.205.119.208 with SMTP id fv16mr5900390bkc.100.1341858948882; Mon, 09 Jul 2012 11:35:48 -0700 (PDT) Sender: freemanrich@gmail.com Received: by 10.204.4.71 with HTTP; Mon, 9 Jul 2012 11:35:48 -0700 (PDT) In-Reply-To: <86a9z9qurj.fsf@gmail.com> References: <86txyisdcb.fsf@gmail.com> <4FD62561.5090702@gentoo.org> <86395po8sc.fsf_-_@gentoo.org> <86y5n98xl3.fsf_-_@gmail.com> <8662a3y23a.fsf_-_@gmail.com> <4FF4707E.8010304@gentoo.org> <8662a2v0mu.fsf@gmail.com> <4FF594DB.9020109@gentoo.org> <86a9z9qurj.fsf@gmail.com> Date: Mon, 9 Jul 2012 14:35:48 -0400 X-Google-Sender-Auth: F0yNhpycGOdty_ef70Bgip2t99k Message-ID: Subject: Re: [gentoo-soc] [report 6.25-7.4] Daemons in Gentoo Prefix with OpenRC (extended to improving to OpenRC) From: Rich Freeman To: gentoo-soc@lists.gentoo.org Content-Type: text/plain; charset=ISO-8859-1 X-Archives-Salt: 829acee2-2890-40df-ade7-95f2d5ba0b76 X-Archives-Hash: 807b1ae0c2ad893a33be1ada31d3cfab On Mon, Jul 9, 2012 at 3:05 AM, wrote: > Luca Barbato writes: >>> What we've discussed in the beginning, such as event-driven init, >>> periodical events, process monitoring and crash restart are still on >>> the todo list. >> >> That's great, do you feel confident you'll be able to get all of this >> done? > > I feel these are not technically difficult. But the policies count, > besides the debates that if we really need these fancy features for an > init system. My current feeling (or planning) is that just to make dirty > ones with simple scripts to see if our community (debian is more similar > to us than fedora) really like the things. The rule of thumb is to > always make them optional, hopefully independent, components. > As a certified member of the peanut gallery I can testify that process monitoring and restarting would be a very nice feature to have. Having this sort of capability in a chroot/prefix would probably create a bunch of possibilities. Tools for doing this exist, but they are weak. I switched a VM over to systemd because it had an unstable daemon and I wanted to try out this feature. Since systemd places each daemon in a cgroup it is able to fairly effectively monitor what is going on with them. That might be something to keep in mind if you move ahead with this. I don't use a laptop with Gentoo so event-driven init is less useful personally, but I imagine that if I had one it would be very nice to have. Again, I'd look at what upstart/systemd are doing to avoid re-inventing the wheel here. Keep in mind that process restarting is actually a very standard feature in init - we just rarely actually run daemons directly from init. On the occasion that I've actually stuck something in inittab init is very diligent in propping it back up. The challenge will be things like hung processes that don't actually die - but we can start with the simple case. Rich