Date: Mon, 2 May 2016 23:26:04 +0200 From: Jilles Tjoelker <jilles@stack.nl> To: Melissa Jenkins <melissa-freebsd@littlebluecar.co.uk>, Edward Tomasz =?utf-8?Q?Napiera=C5=82a?= <trasz@FreeBSD.org>, freebsd-stable@freebsd.org Subject: Re: 10.3 and reboot -r (reroot) Message-ID: <20160502212604.GA9127@stack.nl> In-Reply-To: <20160419104654.GC5543@brick.home> References: <mailman.13.1446379200.13179.freebsd-stable@freebsd.org> <45B67BCE-540F-432A-9AA2-192B20312D27@littlebluecar.co.uk> <20160419104654.GC5543@brick.home>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20160502212604.GA9127>