Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 11 Mar 2009 13:13:34 +0000 (GMT)
From:      Robert Watson <rwatson@FreeBSD.org>
To:        Nate Eldredge <neldredge@math.ucsd.edu>
Cc:        freebsd-hackers@freebsd.org, vasanth raonaik <vasanth.raonaik@gmail.com>
Subject:   Re: Debugging init process.
Message-ID:  <alpine.BSF.2.00.0903111310280.5537@fledge.watson.org>
In-Reply-To: <Pine.GSO.4.64.0903101900160.3173@zeno.ucsd.edu>
References:  <d9f479c10903100953w4c600775oc06b997b67c472d6@mail.gmail.com> <Pine.GSO.4.64.0903101900160.3173@zeno.ucsd.edu>

next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 10 Mar 2009, Nate Eldredge wrote:

> On Tue, 10 Mar 2009, vasanth raonaik wrote:
>
>> I need to debug init process. I am not able to attach init to gdb and it 
>> throws
>
> As others mentioned, this is explicitly disabled.  You could re-enable it by 
> hacking the kernel, but it could cause other unexpected problems.
>
> Alternatively, there's always "printf debugging".
>
> What is wrong with init, that you need to debug it?  It's a fairly simple 
> program that's been around for a long time and should be pretty stable.

One specific concern with debugging init is that the ptracing application will 
intercept all signals destined for the target application, and since signals 
are used to manage the system run cycle, and init becomes the parent of 
orphaned processes, this could lead to unexpected side effects.  Also, if init 
exits, your system will panic :-).  Last time I mucked with init, I found the 
best ways to debug it were:

(1) Provide a LD_PRELOAD for libc that replaces getpid(), getppid(), and other
     things to return pid 1.

(2) Run init in a jail so that if it exits, the box won't panic.

(3) Use tools like ktrace on the actual init, combined with utrace()
     instrumentation of init so you can track its behavior "in the wild"

FYI, if you do want to clear P_SYSTM, one easy way to do that is to attach 
kgdb to /dev/mem, and directly manipulate the flags on initproc.  This comes 
with some risks, of course. :-)

Robert N M Watson
Computer Laboratory
University of Cambridge



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.0903111310280.5537>