Valgrind as init

James Hunt james.hunt at
Fri Jun 10 16:42:53 UTC 2011

On 08/06/11 22:42, Aidan Thornton wrote:
> On Wed, Jun 8, 2011 at 9:39 PM, Scott James Remnant <scott at> wrote:
>> The problem with valgrind is the same as the general problem with gdb; init
>> needs to be pid 1, and these processes then can't trace it/emulate it.
>> Scott
> Hi,
> This all seems quite familiar. I know initng used to have a kernel
> patch you could apply to work around this issue, though that's long
> since out of date. Not sure if I ever ran valgrind on pid 1 though. In
> fact, I think the big problem was that if it detected a serious enough
> memory access violation, valgrind forcibly terminated init, bypassing
> any SIGSEGV handler and causing a kernel panic due to pid 1 exiting.
> Basically: you don't want to do that. If you need to do so, I suggest
> using a VM with the console attached to somewhere that the messages
> will survive a kernel panic within the VM. If you can somehow manage
> to test whatever it is you need without running upstart as pid 1 that
> will make your life a lot easier.
Agreed. I do a lot of testing using the "--session" option such that you can run Upstart as a
non-priv user and have it talk over your D-Bus session bus:

$ /sbin/init --confdir $HOME/conf/ --session --debug

If you really want to get crazy, you *can* run as root with PID 1 using clone [1]. Here, for
example, is how you invoke gdb:

$ sudo \
  gdb --args \
  init/init --debug --confdir /my/conf/dir --no-startup-event --no-sessions

Where this 2nd instance of Upstart will be running as PID 1 in a different namespace, but will be
listening for D-Bus events on your session bus in the initial namespace. You can then do (from the
original namespace):

$ sudo start <job>

Looks somewhat scary, but it works :)

[1] -

> Hope that helps,
> Aidan
> (Apologies for any duplicates, I sent this from the wrong address.)

More information about the upstart-devel mailing list