Re: kill builtin in ash might behave like killall
Hi, On Fri, Mar 3, 2017 at 3:17 PM, Kang-Che Sungwrote: > 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
Hello, On Fri, Mar 3, 2017 at 1:44 PM, Titowrote: > > > 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
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
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
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