kill builtin in ash might behave like killall

Tito farmatito at tiscali.it
Fri Mar 3 12:44:43 UTC 2017



On 03/03/2017 01:01 PM, Emmanuel Deloget wrote:
> Hello,
>
> I'm using BB 1.26.2 with an heavily modified LEDE where I added
> procps-ng and sysvinit. Given that setup, I'm using /usr/bin/kill from
> props-ng and killall5 from sysvinit, meaning that I have the following
> configuration:
>
> # CONFIG_FEATURE_KILL_REMOVED is not set
> CONFIG_FEATURE_KILL_DELAY=0
> # CONFIG_RFKILL is not set
> # CONFIG_KILL is not set
> CONFIG_KILLALL=y
> # CONFIG_KILLALL5 is not set
> # CONFIG_PKILL is not set
>
> The code in the kill.c applet is quite clear in this case:
>
> ...
> #elif !ENABLE_KILL && ENABLE_KILLALL && !ENABLE_KILLALL5
> # define killall  1
> # define killall5 0
> ...
>
> My problem is that I'm also using ash with job control enabled,
> meaning that while I don't have the kill applet installed, I am still
> using the kill.c code through the kill builtin.
>
> You probably begin to see where I'm going: in this specific case, the
> kill builtin does not work correctly, because it believes it should
> behave as the killall command. And, of course, loads of scripts are
> now unable to work correctly.
>
> The obvious solution would be to disable CONFIG_KILLALL yet I also use
> it from time to time on the command line, so I'd prefer to keep it.
>
> For now, I'm doing a local patch to always check char3. This is
> probably suboptimal yet I cannot see a better solution for this
> specific issue. Does any of you have a better idea?
>
> Best regards,
>
> -- Emmanuel Deloget

Hi,
you could disable CONFIG_KILLALL in your main busybox binary
and create a second binary that contains only the killall
applet and rename it killall, if space is not a problem.

Ciao,
Tito


More information about the busybox mailing list