10.3 and reboot -r (reroot)

[Jilles Tjoelker]

On Tue, Apr 19, 2016 at 12:46:54PM +0200, Edward Tomasz Napierała wrote:
> On 0419T0906, Melissa Jenkins wrote:
> > I've been trying to get reboot -r to work but get an error that
> > kern.proc.pathname is undefined.  It then drops to single user mode.

> > Interestingly I've checked the value of kern.proc.pathname and it
> > appears to be undefined on all the OS boxes we have from 9.3 up to
> > current.  In fact the kern.proc tree doesn't appear to contain
> > anything though it does exist at least on some of the boxes.

> The kern.proc.pathname is a weird sysctl.  It's per-process, and it's
> impossible to access it via name, only by numeric ID.  So, this is
> normal.

> The fact that reroot doesn't work because of this is not normal,
> though. I have no idea why this would fail; I'll investigate.

I can make it fail this way easily by installing a new init(8) binary.
This makes the kern.proc.pathname sysctl fail because /sbin/init has
been moved away or deleted. The command  procstat -b 1  uses the same
vnode-to-pathname translation code and fails similarly.

If only a single install has been done, a command  ls -l /sbin/init*
will make the kernel realize that /sbin/init.bak is in fact the pathname
of process 1's executable, and both  procstat -b 1  and  reboot -r
start working. However, the reroot will use the old init binary to
perform reboot(RB_REROOT) and to find init in the new root file system,
which may be undesirable.

It may be better to use the original argv[0]. The kernel passes a full
pathname here.

While reading the code, I noticed another issue. The kill(-1, SIGKILL)
may fail with [ESRCH] if there is no process to kill. In this case, the
reroot should continue. This problem sometimes occurs for me when
rerooting from single user mode.

-- 
Jilles Tjoelker