From owner-svn-src-all@FreeBSD.ORG Sun Mar 18 23:16:23 2012 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4D98F1065688; Sun, 18 Mar 2012 23:16:23 +0000 (UTC) (envelope-from utisoft@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 6D4248FC15; Sun, 18 Mar 2012 23:16:22 +0000 (UTC) Received: by bkcjc3 with SMTP id jc3so5443483bkc.13 for ; Sun, 18 Mar 2012 16:16:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=oC5YS86OyosJCMp6gRea85f1UzMmykW/nPvWcAsnypo=; b=RyMMgf1MWAW0BojnAISXRH0MkNPuBG9hhC8B44RMXZ5bEeLoSkZ+7PgKklQgeTI+73 N2vY8r9XP8MDax7PDQ6IfOSgVz5elXKbdja5vJcGeE4vrhYjuJ0kl+ZC6naC7Og6H4qP fP2KiUrMw2jwM6gZ3BoWTyaSL41AmqPvdRStfLbC1+h/T3ZZ/kvev8OOHCQIBWcO4MAj 4GivIvVGZiR/NJ4x/3BBwVgenGNy+/MDsTqJsIgXUarMNLImenW0SmP2lkPjRS+QB/vV bxcSqTQXcWFLlYoMGNmt3jGbjRpEyGOXhrf0wbPvoHIUAG7WVr7YPV4jCNlV+sWczdQY 0MGA== MIME-Version: 1.0 Received: by 10.204.132.80 with SMTP id a16mr3848595bkt.18.1332112581387; Sun, 18 Mar 2012 16:16:21 -0700 (PDT) Received: by 10.204.202.142 with HTTP; Sun, 18 Mar 2012 16:16:21 -0700 (PDT) Received: by 10.204.202.142 with HTTP; Sun, 18 Mar 2012 16:16:21 -0700 (PDT) In-Reply-To: <1331852174.8403.12.camel@revolution.hippie.lan> References: <201203141622.q2EGM9HR021407@svn.freebsd.org> <1331852174.8403.12.camel@revolution.hippie.lan> Date: Sun, 18 Mar 2012 23:16:21 +0000 Message-ID: From: Chris Rees To: Ian Lepore Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, Ed Schouten Subject: Re: svn commit: r232977 - in head: etc sbin/init X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Mar 2012 23:16:23 -0000 On 15 Mar 2012 22:57, "Ian Lepore" wrote: > > On Wed, 2012-03-14 at 16:22 +0000, Ed Schouten wrote: > > Author: ed > > Date: Wed Mar 14 16:22:09 2012 > > New Revision: 232977 > > URL: http://svn.freebsd.org/changeset/base/232977 > > > > Log: > > Make init(8) slightly more robust when /dev/console is missing. > > > > If the environment doesn't offer a working /dev/console, the existing > > version of init(8) will simply refuse running rc(8) scripts. This means > > you'll only have a system running init(8) and nothing else. > > > > Change the code to do the following: > > > > - Open /dev/console like we used to do, but make it more robust to use > > O_NONBLOCK to prevent blocking on a carrier. > > - If this fails, use /dev/null as stdin and /var/log/init.log as stdout > > and stderr. > > Given that the /var filesystem is mounted (and with readonly root, > actually created) by an rc script run by init, does this make sense? > Maybe it makes sense only within a jail, but not when running as pid 1? > > > - If even this fails, use /dev/null as stdin, stdout and stderr. > > > > So why us this useful? Well, if you remove the `getpid() == 1' check in > > main(), you can now use init(8) inside jails to properly execute rc(8). > > It still requires some polishing, as existing tools assume init(8) has > > PID 1. > > Not just existing tools, but 3rd party software is likely to contain > this assumption (I know some of ours does). The manpage for init > contains examples of using a hard-coded 1. Would it be practical for > any reference to pid 1 to get somehow magically redirected inside a jail > to the pid of an init process running within that jail? That's just a > pure blue-sky idea that popped into my head; I know almost nothing about > jails (their implementation or how to use them). > Not really. Processes are given a 'jailed' property, but apart from that are just regular processes. Also, faking PIDs like that will also hide the host (real) init.... though whether that is a problem or not is an exercise for the reader. Chris