Re: Please review sh SIGSTOP fix
In <[EMAIL PROTECTED]>, Martin Cracauer wrote: > If you really want to background one process from /etc/rc, you would > still do that by writing a wrapped that catches SIGINT and send ^^^ ^ wrapper shellscript s > SIGSTOP to its child (which is the original thing to start). Sorry Martin -- Martin Cracauer <[EMAIL PROTECTED]>http://www.cons.org/cracauer/ As far as I'm concerned, if something is so complicated that you can't ex- plain it in 10 seconds, then it's probably not worth knowing anyway -Calvin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Please review sh SIGSTOP fix
In <[EMAIL PROTECTED]>, Randell Jesup wrote: > Martin Cracauer <[EMAIL PROTECTED]> writes: > >would you please have a look at the following sh fix? My brain is a > >bit rusty and maybe I overlook a drawback. > > > >When a child is receiving SIGSTOP, eval continues with the next > >command. While that is correct for the interactive case (Control-Z > >and you get the prompt back), it is wrong for a shellscript, which > >just continues with the next command, never again waiting for the > >stopped child. Noted when childs from cronjobs were stopped, just to > >make more processes (by wosch). > > Careful - is this behavior used as a feature during boot when > starting services? I.e. you can ^Z and it will continue with the next > service; effectively backgrounding the service that's waiting. I.e. is > this a feature (perhaps accidental) that people assume and rely on? I hope not, thats definitivly a bug. Do you intent to continue the stopped proccess anytime? I don't think that are many cases where they were hung so that backgrounding them is needed but where they are not completely hung. > And > if so, is there another way to get the functionality, and is it important > to people? Control-C kills the currently starting process and Control-\ makes the whole /etc/rc return to singleuser-mode. That are the only documented ways to interact with /etc/rc. If you really want to background one process from /etc/rc, you would still do that by writing a wrapped that catches SIGINT and send SIGSTOP to its child (which is the original thing to start). Martin -- Martin Cracauer <[EMAIL PROTECTED]>http://www.cons.org/cracauer/ As far as I'm concerned, if something is so complicated that you can't ex- plain it in 10 seconds, then it's probably not worth knowing anyway -Calvin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Please review sh SIGSTOP fix
Martin Cracauer <[EMAIL PROTECTED]> writes:
>would you please have a look at the following sh fix? My brain is a
>bit rusty and maybe I overlook a drawback.
>
>When a child is receiving SIGSTOP, eval continues with the next
>command. While that is correct for the interactive case (Control-Z
>and you get the prompt back), it is wrong for a shellscript, which
>just continues with the next command, never again waiting for the
>stopped child. Noted when childs from cronjobs were stopped, just to
>make more processes (by wosch).
Careful - is this behavior used as a feature during boot when
starting services? I.e. you can ^Z and it will continue with the next
service; effectively backgrounding the service that's waiting. I.e. is
this a feature (perhaps accidental) that people assume and rely on? And
if so, is there another way to get the functionality, and is it important
to people?
Perhaps I'm totally wrong here and misunderstood the issue.
--
Randell Jesup, Worldgate Communications, ex-Scala, ex-Amiga OS team ('88-94)
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Please review sh SIGSTOP fix
Bruce (or other -currenter's)
would you please have a look at the following sh fix? My brain is a
bit rusty and maybe I overlook a drawback.
When a child is receiving SIGSTOP, eval continues with the next
command. While that is correct for the interactive case (Control-Z
and you get the prompt back), it is wrong for a shellscript, which
just continues with the next command, never again waiting for the
stopped child. Noted when childs from cronjobs were stopped, just to
make more processes (by wosch).
The fix is not to return from a job wait when the wait returned for a
stopped child while in non-interactive mode. This bahaviour seems to
be what bash2 and ksh implement. I tested for correct behaviour for
finnaly killing the child with and without forgrounding it first.
When not foregrouding before killing, the shell continues with the
script, which is what the other shells do as well.
Thanks
Martin
Index: jobs.c
===
RCS file: /home/CVS-FreeBSD/src/bin/sh/jobs.c,v
retrieving revision 1.27.2.1
diff -u -r1.27.2.1 jobs.c
--- jobs.c 2000/06/14 13:42:25 1.27.2.1
+++ jobs.c 2001/02/02 10:28:08
@@ -782,7 +782,8 @@
do {
pid = waitproc(block, &status);
TRACE(("wait returns %d, status=%d\n", pid, status));
- } while (pid == -1 && errno == EINTR && breakwaitcmd == 0);
+ } while ((pid == -1 && errno == EINTR && breakwaitcmd == 0) ||
+ (WIFSTOPPED(status) && !iflag));
in_dowait--;
if (breakwaitcmd != 0) {
breakwaitcmd = 0;
--
Martin Cracauer <[EMAIL PROTECTED]>http://www.cons.org/cracauer/
As far as I'm concerned, if something is so complicated that you can't ex-
plain it in 10 seconds, then it's probably not worth knowing anyway -Calvin
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
