On 09-Feb-16, Olaf Dabrunz wrote:
> On 09-Feb-16, Olaf Dabrunz wrote:
> > On 09-Feb-16, Olaf Dabrunz wrote:
> > > Ah right, you already use this in 7.4.1274.
> > >
> > > To correct myself: kill the negative of the PID of the session leader,
> > > this sends the signal to all processes in its process group (!), see
> > > kill(2):
> > >
> > > mch_stop_job():
> > >
> > > sig = atoi((char *)how);
> > > else
> > > return FAIL;
> > > - kill(job->jv_pid, sig);
> > > + kill(-job->jv_pid, sig);
> > > return OK;
> > > }
> > > #endif
> > >
> > >
> > > This also triggers a sort of chain reaction that should bring down the
> > > other process groups in the session (if any), unless they ignore SIGHUP:
> > >
> > > When the session leader exits, all processes in the foreground
> > > process receive a SIGHUP.
> > >
> > > When the parent (typically the session leader) of a background
> > > process group with at least one stopped process exits, all processes
> > > in that background process group receive a SIGHUP. (And a SIGCONT,
> > > which makes them continue running in the background in case they
> > > ignore SIGHUP.)
> >
> > Processes that are not terminated by this chain reaction are
> > - in a background process group where all processes are running
> > (long running compute jobs)
> > $ break_encryption &
Hrm. An *interactive* shell terminates even *running* background
processes, so the "nohup" is needed (man bash):
The shell exits by default upon receipt of a SIGHUP. Before
exiting, an interactive shell resends the SIGHUP to all jobs,
running or stopped.
But when started from a non-interactive shell, a running background
process should not be terminated.
> The python process started from the shell in your example must have been
> in its own process group and only blocked on reading from a socket, but
> not stopped by a signal.
>
> So you essentially started it as a long running compute job, which is
> unaffected by session termination.
>
> Gary's suggestion to use
>
> /bin/sh -c "exec python demoserver.py <here >there"
>
> should fix this, by replacing the session leader shell with the python
> process executing demoserver.py, so it is not in a separate process
> group and affected directly by either kill(job->jv_pid, sig) or
> kill(-job->jv_pid, sig).
>
> > - background processes that choose to survive session termination,
> > even when temporarily stopped
> > $ nohup break_encryption &
> > $ kill -STOP %1 # give me some processing power now
> >
> > Daemons detach even further, by leaving the session.
> >
> > > See more details in
> > > - http://www.win.tue.nl/~aeb/linux/lk/lk-10.html#ss10.3
> > > - man 2 setpgid
--
Olaf Dabrunz (oda <at> fctrace.org)
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
