Re: problems with a subhurd
Hello, Olaf Buddenhagen writes: > On Sun, Sep 04, 2016 at 12:34:09PM +0200, Justus Winter wrote: > >> I recommend against shutting down subhurds. > > This is a regression, though -- I'm pretty sure I used `halt` and/or > `reboot` in subhurds in the past. (Sometimes it failed; but it never > broke my main instance IIRC...) Ok, let me clarify: I recommend against shuttind down subhurds running sysvinit, like Debian. Sysvinit shutdown of the subhurd will killall processes of the parent hurd. If you must, always use 'halt -f', or 'halt-hurd'. This will circumvent the sysvinit shutdown, and merely execute the hurd shutdown, which is safe. Also let me stress that this is not a regression. Traditional subhurds were very careful not to harm the parent hurd despite having the privileges to do so. We have extra code in /hurd/startup dealing with being a "nice" privileged subhurd. However, that has never been robust, the parents processes were always accessible from the subhurd. In any case, with the new unprivileged subhurds any shutdown procedure is fine. Justus signature.asc Description: PGP signature
Re: problems with a subhurd
Hi, On Sun, Sep 04, 2016 at 12:34:09PM +0200, Justus Winter wrote: > I recommend against shutting down subhurds. This is a regression, though -- I'm pretty sure I used `halt` and/or `reboot` in subhurds in the past. (Sometimes it failed; but it never broke my main instance IIRC...) -antrik-
Re: problems with a subhurd
Hey :) "Brent W. Baccala" writes: > Our current setup is that PID 5 (ext2fs) runs first, then starts PID 2 > (startup), which starts PID 1 (init). Weird. The cleanest solution, of > course, would be to have proc actually respect these parenting > relationships, then SIGCHLD and waitpid() would work normally. Yes, weird indeed. /hurd/proc assigns pids as the tasks are discovered, and I hacked it so that we can make sysvinit pid 1. sysvinit (posix?) expects that. > 3. Booting the subhurd, then running "halt -f" from its shell crashes the > parent Hurd. Here's what the subhurd displays: I recommend against shutting down subhurds. Privileged subhurds (privileged as in the do have the privileged host control port) can power down the system. Also, the subhurd can see tasks from the parent hurd, and interact with them. If you like, you can have a look at my unprivileged subhurd branch here: http://darnassus.sceen.net/cgit/teythoon/hurd.git/log/?h=unprivileged-subhurds-2016-09-04 Cheers, Justus signature.asc Description: PGP signature
Re: problems with a subhurd
Hello, Brent W. Baccala, on Wed 31 Aug 2016 13:35:07 -1000, wrote: > Also, after fixing bug #1, this screws up startup's attempt to start a new > shell if the old one dies. Note that even on success, "try" is incremented, i.e. /bin/shd is tried instead of the shell. > Maybe startup shouldn't > try to start a second init, even if the first one dies. No, we probably do want to run a shell in case the runsystem dies unexpectedly. Samuel
