init problems (feature or bug?)

Dirk Clemens develop at cle-mens.de
Mon Jan 8 13:13:51 UTC 2007


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I have found an init problem:

- --------------- Example 1 ---------------


- --- file /etc/inittab ---
::shutdown:/etc/halt
- --- end --

- --- file /etc/halt ---
kill -TERM -1
sleep 5
kill -KILL -1
sleep 5
umount -a
- --- end --

After the first kill, /etc/halt will also be terminated.
The second kill will never be executed.


- --------------- Example 2 ---------------

- --- file /etc/inittab ---
::shutdown:/etc/halt1
::shutdown:/etc/halt2
- --- end --

- --- file /etc/halt1 ---
kill -TERM -1
sleep 5
kill -KILL -1
sleep 5
- --- end --

- --- file /etc/halt2 ---
sleep 20
do_something
- --- end --

After the first kill /etc/halt2 is started and both
/etc/halt1 and /etc/halt2 runs at same time.


- -----------------

The reason is: init creates a sub process (#A) and that
sub process create a new sub process (#B) which will execute
the code or script. And #A is not roust against signals.
So if the script in #B uses 'kill -TERM -1', #A will be
killed and init thinks, that the job has finished

In example 1 init thinks that shutdown is done
and kills itself all other processes.

In example 2 init thinks that halt1 is done and
starts halt2, so that both runs together.

I have the same effects when using bash internal kill
or busybox kill.

At the moment I use this as workaround:

- --- file /etc/inittab ---
::shutdown:/bin/kill -TERM -1
::shutdown:/bin/sleep 5
::shutdown:/bin/kill -KILL -1
::shutdown:/bin/sleep 1
::shutdown:/etc/rc.d/halt
- --- end --
Not nice, but it works.

And when logging the 'ps' output in halt I see, that both
kill procces are zombies, because their parents doesn't wait.


Dirk
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (MingW32)

iD8DBQFFokOPvXSNhmcsHaMRAkuYAJ4tMxYgt/IiyjkD2b0s3UGCgZZMxACfZnDB
uNMsoYEd3GXxsz0J7xH66uM=
=Jgxt
-----END PGP SIGNATURE-----



More information about the busybox mailing list