Re: killall behaviour
Hi Denys ! killall matches by /proc/PID/exe too. Because some applets use a trick where they re-execute themselves by execve(/proc/self/exe). When you do that, /proc/PID/comm field gets set to string exe :( Thus, matching by comm will fail to find a process started this way. ... but here we start a program by different name, just pointing to same executable, when you do a killall nobody expects to kill other instances of the same executable, when called with a different name. May be this /proc/self/exe is a special case, which shall only trigger the test on /proc/PID/exe when the comm field contains exe, else you highly risk killing the wrong processes. As you can see the comm fields contains the expected values, and would select the right processes here. -- Harald ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: killall behaviour
On Fri, Sep 5, 2014 at 1:21 PM, Harald Becker ra...@gmx.de wrote: killall matches by /proc/PID/exe too. Because some applets use a trick where they re-execute themselves by execve(/proc/self/exe). When you do that, /proc/PID/comm field gets set to string exe :( Thus, matching by comm will fail to find a process started this way. ... but here we start a program by different name, just pointing to same executable, when you do a killall nobody expects to kill other instances of the same executable, when called with a different name. Unfortunately, there is no commonly agreed definition of program named FOO. If it is the same executable, is it the same program? You can about as easily argue that killing by looking at basename(argv[0]) is wrong, because argv[0] can be anything: execve(/bin/foo, [ha ha you lose, ... ]). You can also easily argue that killing by looking at comm is wrong too, because comm is truncated to 15 chars, and is settable by a prctl. So, the proper solution, which never kills wrong processes, is killall should kill no processes. -- vda ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: inittab: Start shell only if console is not null
On Thu, Aug 28, 2014 at 4:38 PM, Harald Becker ra...@gmx.de wrote: Denys ! My argument is that before adding code, it makes sense to ponder whether we really have a real problem here. Do you really insist on this endless respawning NOT BEING A BUG??? I'm saying it is not clear-cut. If one respawn per second a big problem? I'm not sure. Problem means it may make diagnosing other problems a hell. Why is it hell? strace -p1 works. It is the reason I neglect to use unpatched Busybox init for most of my applications and I know several people here in Germany thinking the same that this is really bad. I really wonder why this has not bean fixed earlier (anyhow not insisting on my patch). I even asked for this around 1995 to 1997 (as far as I remember), but it has been neglected due to the KISS principle and things shall be small for embedded devices ... but today we got more and more desktop related patches blowing up things more than that simple approach. And still you insist on this endless uncontrolled respawning? If you really like this endless respawning, why don't you use runit? You are right, I do not use init. Respawn on error is not the only, or the biggest problem it has. http://busybox.net/~vda/init_vs_runsv.html ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: inittab: Start shell only if console is not null
Hi Denys ! Problem means it may make diagnosing other problems a hell. Why is it hell? strace -p1 works. If you have a working strace ... ... or in other words: Do you have a working Busybox applet for this? You are right, I do not use init. Respawn on error is not the only, or the biggest problem it has. http://busybox.net/~vda/init_vs_runsv.html Ok, this story is funny to read, but has nothing to do with the problems of Busybox init. And still there are people which dislike this runit/runsv/runsvdir. I'm highly disagreeing with all that information of daemons being scattered around so many directories and subdirectories and files. I tried this and I got lost on even simple systems. That's definitely not the way I like to have my system. ... but that does not change my mind, that Busybox init has a long standing bug of uncontrolled and endless respawning processes, and it's now at the time to solve this bug, anyhow! I posted a simple change which stops this endless respawning for some kinds of problems, until init gets a SIGHUP (reload inittab). - This catches open problems with the console (a case which may be detected in master, but this one is the only case, which may be handled there). - Exec failures, which usually return with status -1, stop the respawning. - Getty may return status -1 for open problems (e.g. all pre login prompt problems), and for problems when exec to login (as it was done in several gettys I used). This won't endless respawn this console, until someone could fix the reason and does a SIGHUP. sysinit and runonce actions get not affected, and respawn actions usually run after sysinit actions have gone, so system resources shall all be available to start respawning. If a process exits with any other value except the well known -1 status, or if a process is terminated by a signal, it is always triggered for restart and not stopped. ... but other solutions to fix the problem may also be welcome ... but not if only unspecific redirection to use a different init mechanics. -- Harald ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [Bug: Busybox 1.22.1] false return 0 instead of 1 with '--help' switch.
Hello list, I want to highlight what GNU coreutils' help docs (info coreutils 'false invocation') says about false when invoked with --help: Note that `false' (unlike all other programs documented herein) exits unsuccessfully, even when invoked with `--help' or `--version'. I think Busybox should do the same with the applet. Cheers, Xabier Oneca_,,_ ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: killall behaviour
Hi Denys ! Unfortunately, there is no commonly agreed definition of program named FOO. ... but standard usage cases should be acted on correct: Think of: ln -s /bin/Busybox ntpd ln -s /bin/Busybox syslogd ln -s /bin/Busybox klogd ntpd ... syslogd ... klogd ... Busybox killall ntpd ... will not only kill ntpd, but also syslogd and klogd ... do you think anyone expect this? So, the proper solution, which never kills wrong processes, is killall should kill no processes. Where is your upstream compatibility here??? ... this is not a corner case problem! -- Harald ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [Bug: Busybox 1.22.1] false return 0 instead of 1 with '--help' switch.
Hello again, 2014-09-05 18:19 GMT+02:00 Xabier Oneca -- xOneca xon...@gmail.com: Hello list, I want to highlight what GNU coreutils' help docs (info coreutils 'false invocation') says about false when invoked with --help: Note that `false' (unlike all other programs documented herein) exits unsuccessfully, even when invoked with `--help' or `--version'. I think Busybox should do the same with the applet. And I want to add that --help will only be used ever in an interactive shell by a person, so the return value may be dispensable. (i.e. doesn't mind to the user how does --help return as soon as the help text is printed in screen) Cheers, Xabier Oneca_,,_ ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [Bug: Busybox 1.22.1] false return 0 instead of 1 with '--help' switch.
Xabier Oneca -- xOneca wrote: Hello again, 2014-09-05 18:19 GMT+02:00 Xabier Oneca -- xOneca xon...@gmail.com: Hello list, I want to highlight what GNU coreutils' help docs (info coreutils 'false invocation') says about false when invoked with --help: Note that `false' (unlike all other programs documented herein) exits unsuccessfully, even when invoked with `--help' or `--version'. I think Busybox should do the same with the applet. And I want to add that --help will only be used ever in an interactive shell by a person, so the return value may be dispensable. (i.e. doesn't mind to the user how does --help return as soon as the help text is printed in screen) Actually this is the argument to leave it as it is, because nobody cares about the return value of false --help. It might be nice if false --help would return false, but it would add extra code to busybox for no real benefit. ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [Bug: Busybox 1.22.1] false return 0 instead of 1 with '--help' switch.
i.e.: GNU false --help `fails', just like in POSIX and in Busybox's `other false' (the builtin false/falsecmd() in ash). So can we just fix it? What did you think of the patch that I sent? On 2014-09-03 11:13, Denys Vlasenko wrote: $ /bin/false --version false (GNU coreutils) 8.7 ... $ /bin/false --help; echo $? Usage: /bin/false [ignored command line arguments] or: /bin/false OPTION Exit with a status code indicating failure. --help display this help and exit --version output version information and exit NOTE: your shell may have its own version of false, which usually supersedes the version described here. Please refer to your shell's documentation for details about the options it supports. Report false bugs to bug-coreut...@gnu.org GNU coreutils home page: http://www.gnu.org/software/coreutils/ General help using GNU software: http://www.gnu.org/gethelp/ Report false translation bugs to http://translationproject.org/team/ For complete documentation, run: info coreutils 'false invocation' 1 -- 'tis an ill wind that blows no minds. ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [Bug: Busybox 1.22.1] false return 0 instead of 1 with '--help' switch.
Hello Ralf, El 05/09/2014 18:26, Ralf Friedl ralf.fri...@online.de escribió: Xabier Oneca -- xOneca wrote: Hello again, 2014-09-05 18:19 GMT+02:00 Xabier Oneca -- xOneca xon...@gmail.com: Hello list, I want to highlight what GNU coreutils' help docs (info coreutils 'false invocation') says about false when invoked with --help: Note that `false' (unlike all other programs documented herein) exits unsuccessfully, even when invoked with `--help' or `--version'. I think Busybox should do the same with the applet. And I want to add that --help will only be used ever in an interactive shell by a person, so the return value may be dispensable. (i.e. doesn't mind to the user how does --help return as soon as the help text is printed in screen) Actually this is the argument to leave it as it is, because nobody cares about the return value of false --help. What I was trying to say is that if a script appends --help to /bin/false because of a poorly sanitized user input, it should still return 1. And this change in behaviour wont not break any script nor user interaction with the applet. (Maybe even fixes some scripts!) It might be nice if false --help would return false, but it would add extra code to busybox for no real benefit. How many bytes are in game here? Cheers, Xabier Oneca_,,_ ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [Bug: Busybox 1.22.1] false return 0 instead of 1 with '--help' switch.
Xabier Oneca -- xOneca wrote: And I want to add that --help will only be used ever in an interactive shell by a person, so the return value may be dispensable. (i.e. doesn't mind to the user how does --help return as soon as the help text is printed in screen) Actually this is the argument to leave it as it is, because nobody cares about the return value of false --help. What I was trying to say is that if a script appends --help to /bin/false because of a poorly sanitized user input, it should still return 1. And this change in behaviour wont not break any script nor user interaction with the applet. (Maybe even fixes some scripts!) Do you have an example of any real word script that passes any arguments (user supplied or not) to /bin/false ? ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
