[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: When kill does not work for a sudo process in a script?
From: |
Peng Yu |
Subject: |
Re: When kill does not work for a sudo process in a script? |
Date: |
Tue, 2 Mar 2021 08:04:08 -0600 |
OK. This works as I expect.
What does the sequence of underlying C function calls look like when
bash calls an external program with `set -m` enabled? Thanks.
On 3/2/21, Seth David Schoen <schoen@loyalty.org> wrote:
> Peng Yu writes:
>
>> Hi,
>>
>> When I finish running ./main.sh, the forever.sh sudo process will not
>> be terminated. But I tried to kill the forever.sh sudo process in
>> main.sh. But if I remove the two "sudo" words in main.sh, then the
>> forever.sh process can be terminated.
>>
>> Does anybody know why the forever.sh sudo process will not be
>> terminated? Thanks.
>
> I was surprised by this behavior, but it turns out it's more about sudo
> than about bash. The sudo program has a complicated logic about when
> it will or won't forward signals that it catches to the subprocess that
> it's spawned. In this case the relevant logic is one about not
> forwarding signals from processes in the same process group as the
> original sudo command. See the section beginning
>
> /*
> * Do not forward signals sent by a process in the command's
> process
> * group, as we don't want the command to indirectly kill itself.
> * For example, this can happen with some versions of reboot that
> * call kill(-1, SIGTERM) to kill all other processes.
> */
>
> in src/exec_pty.c and src/exec_nopty.c.
>
> I've rarely had occasion to think about the precise circumstances under
> which programs spawned by the same shell are or aren't in the same process
> group (in particular, it seems like there's an issue that job control
> works slightly differently behind the scenes in shell scripts than in
> interactive shells, although I haven't delved into that), but in this case
> it matters a lot because sudo is explicitly checking for this condition.
>
> I was able to nullify this with "set -m" in bash, which uses a different
> process group for every external program that a shell script spawns.
> With the addition of "set -m", the program does what I think you expected.
>
> --
> Seth David Schoen <schoen@loyalty.org> | Qué empresa fácil no pensar
> http://www.loyalty.org/~schoen/ | en un tigre, reflexioné.
> | -- Borges, "El Zahir"
>
--
Regards,
Peng