bug#1112: 23.0.60; Child process not cleaned up properly

[Sven Joachim <svenjoac@gmx.de>]

On 2008-10-07 17:15 +0200, Brent Goodrick wrote:

> 1. M-x compile
> 2. Enter in: sudo apt-get install gimp-help-en
> 3. See the apt-get prompt:
>    Reading package lists... 0%
>    <snip>
>    The following extra packages will be installed:
>      gimp-help-common
>    The following NEW packages will be installed:
>      gimp-help-common gimp-help-en
>    0 upgraded, 2 newly installed, 0 to remove and 1 not upgraded.
>    Need to get 15.9MB of archives.
>    After this operation, 27.5MB of additional disk space will be used.
>    Do you want to continue [Y/n]?
> 4. Kill the buffer, and expect the underlying process to die, just
>    like you would have if you had typed the above command in a shell
>    buffer.

Won't work for processes run under sudo, see below.

> 5. Open up a shell, and type ps to see that the apt-get process still
>    exists
> 6. Go through step 1 again and notice now that a lock is being
>    reported by the second apt-get session because the first process
>    was not properly torn down by the act of killing the previous
>    compilation buffer.
>
> My assessment: The shell mode somehow works differently than the
> compilation mode since the compilation mode does not allow user
> input. Fair enough, but the two modes should work the same in terms of
> tearing down the two processes if the buffers are killed, and should
> not ever leave dormant child processes.

The real problem is that sudo is suid root and thus the compilation
process runs with superuser rights.  Emacs is simply lacking the
privileges to kill it.

You can try something similar in your shell:

,----
| % sudo sleep 1000 &
| [1] 2186
| % kill %1
| kill: kill %1 failed: operation not permitted
| % sudo kill $(pidof sleep)
| [1]  + 2186 terminated  sudo sleep 1000
| %
`----

Sven