Re: ash buildin "read" interrupted on SIGCHLD
On Thu, Jun 1, 2017 at 5:36 PM, Guido Classen wrote: > I was curious how to catch SIGCHLD using trap and what behavior we should > expect. Could you also provide a test for trap in conjunction with SIGCHLD. I was about to ask the same question, until I realize that the SIGCHLD handling behavior with respect to `trap` command is never standardized and varies among shells. > Here my tries with results from busybox-git with your fix: > > # sleep 1& read x > => no trap signal handler installed, read waits now forever for input This is expected behavior in all shells and is included in BusyBox testsuite. > # trap "echo --TRAP---" CHLD; sleep 1& read x > --TRAP--- > [1]+ Done sleep 1 > > => Okay, read will be interrupted after one second >(this works now thanks your fixes in signal handling coder. > It would not work correctly in busybox 1.24 versions) For `ash` (and `dash` also), this would interrupt `read`. But for `hush`, (and `ksh93` according to my testing), this will run the SIGCHLD handler, but after that the `read` command is executed again and it waits for user input. (The least desirable behavior I've ever seen is in `bash`, where it _blocks_ SIGCHLD altogether during the `read` command, and executes the handler only after the `read` is finished.) > # sleep 1& read x > --TRAP--- > [1]+ Done sleep 1 > > => Okay, trap handler still installed, same in subsequent commands A shell's trap handler is not reset after executing the handler, unless you tell to reset it within the handler. Required by POSIX, actually. (http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#trap "Traps shall remain in place for a given shell until explicitly changed with another trap command.") > # trap '' CHLD > # sleep 1& read x > [1]+ Done sleep 1 > > => Is this correct? Set SIGCHLD to ignore, read still will be >interrupted after one second. I'm not sure about this. Sorry. ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: ash buildin "read" interrupted on SIGCHLD
On 22 May 2017 at 19:43, Denys Vlasenko wrote: >> I am not sure what is the right place to fix this. Any comment on this? >> For me it works to suppress this signal on the corresponding poll() call. > > Well, SIGCHLD may have a trap, so, that would not be correct. > > Fixed in git, please try. Thanks for your fix. Works perfect for my script (controlling a cellular modem) I was curious how to catch SIGCHLD using trap and what behavior we should expect. Could you also provide a test for trap in conjunction with SIGCHLD. Here my tries with results from busybox-git with your fix: # sleep 1& read x => no trap signal handler installed, read waits now forever for input # trap "echo --TRAP---" CHLD; sleep 1& read x --TRAP--- [1]+ Done sleep 1 => Okay, read will be interrupted after one second (this works now thanks your fixes in signal handling coder. It would not work correctly in busybox 1.24 versions) # sleep 1& read x --TRAP--- [1]+ Done sleep 1 => Okay, trap handler still installed, same in subsequent commands # trap '' CHLD # sleep 1& read x [1]+ Done sleep 1 => Is this correct? Set SIGCHLD to ignore, read still will be interrupted after one second. # trap - CHLD # sleep 1& read x => Okay, set SIGCHLD to default. read now waits for ever again. ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: ash buildin "read" interrupted on SIGCHLD
On 22 May 2017 at 19:43, Denys Vlasenko wrote: >> I am not sure what is the right place to fix this. Any comment on this? >> For me it works to suppress this signal on the corresponding poll() call. > > Well, SIGCHLD may have a trap, so, that would not be correct. > > Fixed in git, please try. Thanks for your fix. Works perfect for my script (controlling a cellular modem) I was curious how to catch SIGCHLD using trap and what behavior we should expect. Could you also provide a test for trap in conjunction with SIGCHLD. Here my tries with results from busybox-git with your fix: # sleep 1& read x => no trap signal handler installed, read waits now forever for input # trap "echo --TRAP---" CHLD; sleep 1& read x --TRAP--- [1]+ Done sleep 1 => Okay, read will be interrupted after one second (this works now thanks your fixes in signal handling coder. It would not work correctly in busybox 1.24 versions) # sleep 1& read x --TRAP--- [1]+ Done sleep 1 => Okay, trap handler still installed, same in subsequent commands # trap '' CHLD # sleep 1& read x [1]+ Done sleep 1 => Is this correct? Set SIGCHLD to ignore, read still will be interrupted after one second. # trap - CHLD # sleep 1& read x => Okay, set SIGCHLD to default. read now waits for ever again. ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: ash buildin "read" interrupted on SIGCHLD
On Tue, May 9, 2017 at 11:14 AM, Guido Classen wrote: > Hi, > > I've observed some strange behavior in ash buildin "read" when > a SIGCHLD arrives in current busybox. > > old behavior on busybox 1.24.2 ash (same behavior also on Debian bash and > dash) > >sleep 1& read x > => waits for ever until input is given > > new behavior on busybox > > sleep 1& read x >[1]+ Done sleep 1 >=> read will be interrupted after one second due raise of SIGCHLD Oops... > I am not sure what is the right place to fix this. Any comment on this? > For me it works to suppress this signal on the corresponding poll() call. Well, SIGCHLD may have a trap, so, that would not be correct. Fixed in git, please try. ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
