Re: kill builtin in ash might behave like killall

2017-03-03 Thread Emmanuel Deloget
Hi,

On Fri, Mar 3, 2017 at 3:17 PM, Kang-Che Sung  wrote:
> 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
>
> I think I have proposed a patch that fixes this and it's on master now.
>
> Here, if you can adapt it and apply it for yourself:
> https://git.busybox.net/busybox/commit/?id=61a91af63dbc91f85058efda5c542dfc859ab1be

I missed it. And yeah, it does exactly what I want to do.

Thanks for your help!

-- Emmanuel Deloget
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox


Re: kill builtin in ash might behave like killall

2017-03-03 Thread Emmanuel Deloget
Hello,

On Fri, Mar 3, 2017 at 1:44 PM, Tito  wrote:
>
>
> 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

Thanks Tito, but unfortunatly that would mean to change the way LEDE
packages are built (which is way harder than applying my small,
miserable patch on top of BB source).

Space is not much an issue, yet having a full BB binary for killall is
a bit, well, overkill. It would be far simpler to add psmisc as a LEDE
package. But the best solution would still be to fix the kill applet,
since the configuration I use is a valid configuration (and the kill
builtin should never behave as killall, whatever the configuration
is).

Best regards,

-- Emmanuel Deloget
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox


Re: kill builtin in ash might behave like killall

2017-03-03 Thread Kang-Che Sung
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

I think I have proposed a patch that fixes this and it's on master now.

Here, if you can adapt it and apply it for yourself:
https://git.busybox.net/busybox/commit/?id=61a91af63dbc91f85058efda5c542dfc859ab1be
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox


Re: kill builtin in ash might behave like killall

2017-03-03 Thread Tito



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
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox


kill builtin in ash might behave like killall

2017-03-03 Thread Emmanuel Deloget
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
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox