On 15 Mar 2012 22:57, "Ian Lepore" <free...@damnhippie.dyndns.org> 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 _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
