problem with running "kill -QUIT 1" from init

[Rob Landley]

On Tuesday 27 January 2009 19:31:42 Denys Vlasenko wrote:
> On Tuesday 27 January 2009 03:14, Rob Landley wrote:
> > On Thursday 22 January 2009 22:55:23 Aras Vaichas wrote:
> > > One extra note, I do some trickery with /etc/inittab.
> > >
> > > # cat inittab.new
> > >
> > > ::restart:./upgrade_nand
> > >
> > > I change the existing inittab to run my upgrade script, tell init to
> > > reload the new, and then restore the old one so I can continue testing.
> > >
> > > # cp /etc/inittab inittab.bak
> > > # cp inittab.new /etc/inittab
> > > # kill -1 1
> > > # cp inittab.bak /etc/inittab
> > >
> > > It seems that doing "kill -1 1" from /etc/init/rcS doesn't reload the
> > > inittab.
> >
> > The busybox init is a bit of a hack.
> >
> > I made a largeish stab at cleaning it up during the 1.0.0-pre timeframe,
> > but the source control system was frozen for several months (during the
> > switchover from cvs to svn) so I couldn't check it in, and by the time it
> > was unfrozen I'd had a laptop destroyed and lost the code.  Never got
> > back around to redoing it.
> >
> > The current maintainer has chosen instead to implement a different group
> > of init-like programs (sv, runsv, runsvdir and friends, the "runit"
> > package), which can best be described as "not compatible with Ubuntu's
> > upstart".  That's what he pays attention to, not the original sysv-like
> > init.
> >
> > So my vague impression is that the init implementation in busybox has
> > largely been ignored for some time now...
>
> No Rob, not really. While I do think that basic idea of init being
> responsible for respawning daemons and stuff wasn't too bright, that does
> not mean I will try to force my views on anyone by neglecting init in
> busybox.

*shrug*

A quick glance at the code showed things like:

#if ENABLE_FEATURE_USE_INITTAB
    signal(SIGHUP, reload_signal);
#else
    signal(SIGHUP, SIG_IGN);
#endif

When the whole point of ENABLE macros (defined to 0 or 1) is so you can 
instead use code like:

  if (ENABLE_FEATURE_USE_INITTAB) signal(SIGHUP, reload_signal);
  else signal(SIGHUP, SIG_IGN);

Or even:

  signal(SIGHUP, ENABLE_FEATURE_USE_INITTAB ? reload_signal : SIG_IGN);

And then let the compiler's dead code elimination remove the unnecessary 
static function in the case of a test on a constant.

Thus I thought the code was old because it was still full of #ifdefs.  A 
closer look shows that it's full of #ifdefs for no readily apparent reason.

> On Friday 23 January 2009 05:15, Aras Vaichas wrote:
> > I have a working script which allows me to unmount my jffs2 root filing
> > system so I can then write a new image to it. The problem is that it
> > only works when I test run it from a shell prompt. If I run it from my
> > /etc/init/rcS startup script, it doesn't work properly.
>
> Great. "it doesn't work properly". I don't see the script, have no idea
> how it is being run, what reporter expects to see, and what he sees
> instead.
>
> Granted, I could again repeat for a zillionth time the request for more
> info, but I was tired. Sorry.
>
> > I think the problem occurs when I call chroot in the /etc/init/rcS
> > context.
> >
> > Here are the last two lines of my first script:
> > ...
> > ./bin/pivot_root . oldroot
> > ./bin/chroot . ./bin/kill -QUIT 1
>
> "I call chroot in the /etc/init/rcS context". I don't know how reporter
> calls chroot "in the /etc/init/rcS context".

Ok, I see his problem.

He runs a child process, which does a chroot.  This has exactly as much effect 
on the parent process as if his child had done a "cd".  So your child changed 
its context; great.  That doesn't affect any other process on the system.

The _only_ process that runs with the new root is the one chroot spawns, 
specifically "/bin/kill", which presumably finds a "kill" binary to run out of 
its new root filesystem.  That kill binary sends a signal and exits, meaning 
the only process in the system using the new chroot lasts about one clock 
cycle before exiting.

So his init is still running out of the old root.  (There's a reason the 
pivot_root man page calls "exec" in its example.)

What he needs to do is run a shell script _as_ his init process 
(init=/path/to/your/shell/script).  That script will run as pid 1, and he 
needs to have _that_ script call the pivot_root, and have _it_ do the exec 
chroot of his init process so init inherits pid 1.

Rob