� ���, 08.07.2002, � 09:12, Borsenkow Andrej �������:
>
> Unfortunately it does mostly the same. The problem is, init s or init 1
> do not kill the shell that is currently running on console but still
> start yet another instance of (single user) shell. So now you have two
> shells fighting for console input.
>
> There are more problems as single script does as the first thing 'kill
> -9 -1' thus effectively shooting itself in the foot. At least it should
> ...
>
> I'll get a look when time permits.
>
The problem is due to bug in bash. It incorrectly interprets "kill SIG
-1", easy to see:
$ strace -o /tmp/foo bash -c "kill -9 -1"
bash: kill: (1) - Operation not permitted
$ grep kill /tmp/foo
execve("/bin/bash", ["bash", "-c", "kill -9 -1"], [/* 30 vars */]) = 0
kill(1, SIGKILL) = -1 EPERM (Operation not
^^^^^^^^^^^^^^^^
permitted)
write(2, "bash: kill: (1) - Operation not "..., 42) = 42
Look at any other program - you see correct -1.
It means that either bash must be fixed (it must be in any case :-) or
/etc/rc.d/init.d/single must be rewritten in any other language that has
builtin kill and correctly interprets kill -1. It must be builtin, else
single script will kill itself (Linux ignores process that executes kill
SIG -1). ash does not have builtin kill unfortunately.
> About init s - documentation discourages its usage and it is correct
> because none shutdown script is run. Still it _must_ kill everything ...
> and it currently does not do it.
>
It must not. What it does is to kill all _process_groups_ started out of
/etc/inittab. But login shell usually runs in own process group so it is
not killed. Changes to make "init s" work are too extensive. So just to
repeat - do not do it, use init 1 when bash (or single script) are
finally fixed.
-andrej
