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