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 Cracauer <[EMAIL PROTECTED]>  
 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

Reply via email to