parallel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Changing TERM TERM to HUP TERM


From: Gary Johnson
Subject: Re: Changing TERM TERM to HUP TERM
Date: Mon, 18 Mar 2019 00:16:41 -0700
User-agent: Mutt/1.5.20 (2009-06-14)

On 2019-03-17, Ole Tange wrote:
> On Mon, Mar 11, 2019 at 6:48 AM Gary Johnson <address@hidden> wrote:
> >
> > On 2019-03-10, Ole Tange wrote:
> > > To stop GNU Parallel today you need to send TERM to make it stop
> > > starting new jobs followed by another TERM to kill the running jobs.
> :
> > > What is your opinion?
> >
> > A change seems OK, but using HUP for this purpose doesn't seem like
> > a good idea.  Its meaning is specified in the signal(7) man page and
> > that doesn't seem to match your proposed usage.  How about using
> > USR1 or USR2 instead?
> 
> USR1 and USR2 are already used:
> 
> LIST RUNNING JOBS
>        If you want a list of the jobs currently running you can run:
> 
>          killall -USR1 parallel
> 
>        GNU parallel will then print the currently running jobs on
> stderr (standard error).
> 
>            By sending GNU parallel SIGUSR2 you can toggle turning
> on/off --progress on a running GNU parallel process.
> 
> If I look at the list of signals:
> 
> Signal     Value     Action   Comment
> ──────────────────────────────────────────────────────────────────────
> SIGHUP        1       Term    Hangup detected on controlling terminal
>                               or death of controlling process
> SIGINT        2       Term    Interrupt from keyboard
> SIGQUIT       3       Core    Quit from keyboard
> SIGILL        4       Core    Illegal Instruction
> SIGABRT       6       Core    Abort signal from abort(3)
> SIGFPE        8       Core    Floating-point exception
> SIGKILL       9       Term    Kill signal
> SIGSEGV      11       Core    Invalid memory reference
> SIGPIPE      13       Term    Broken pipe: write to pipe with no
>                               readers; see pipe(7)
> SIGALRM      14       Term    Timer signal from alarm(2)
> SIGTERM      15       Term    Termination signal
> SIGUSR1   30,10,16    Term    User-defined signal 1
> SIGUSR2   31,12,17    Term    User-defined signal 2
> SIGCHLD   20,17,18    Ign     Child stopped or terminated
> 
> SIGCONT   19,18,25    Cont    Continue if stopped
> SIGSTOP   17,19,23    Stop    Stop process
> SIGTSTP   18,20,24    Stop    Stop typed at terminal
> SIGTTIN   21,21,26    Stop    Terminal input for background process
> SIGTTOU   22,22,27    Stop    Terminal output for background process
> 
> The signals SIGKILL and SIGSTOP cannot be caught, blocked, or ignored.
> 
> Next the signals not in the POSIX.1-1990 standard but described in
> SUSv2 and POSIX.1-2001.
> 
> Signal       Value     Action   Comment
> ────────────────────────────────────────────────────────────────────
> SIGBUS      10,7,10     Core    Bus error (bad memory access)
> SIGPOLL                 Term    Pollable event (Sys V).
>                                 Synonym for SIGIO
> SIGPROF     27,27,29    Term    Profiling timer expired
> SIGSYS      12,31,12    Core    Bad system call (SVr4);
>                                 see also seccomp(2)
> SIGTRAP        5        Core    Trace/breakpoint trap
> SIGURG      16,23,21    Ign     Urgent condition on socket (4.2BSD)
> SIGVTALRM   26,26,28    Term    Virtual alarm clock (4.2BSD)
> SIGXCPU     24,24,30    Core    CPU time limit exceeded (4.2BSD);
>                                 see setrlimit(2)
> SIGXFSZ     25,25,31    Core    File size limit exceeded (4.2BSD);
>                                 see setrlimit(2)
> 
> I find it pretty clear that I cannot use a signal whose action is
> 'core': Those are not even close in meaning.
> 
> Neither are the ones with the action 'stop'. SIGURG is also not close
> in meaning. SIGCHLD is used actively, so that rules that out.
> 
> So we are in reality down to the ones with action 'term'. And asking
> GNU Parallel not to start more jobs is kind of asking it to terminate
> soonish.
> 
> SIGALRM has a wrong ring to me.
> SIGPIPE will no doubt be triggered by other means.
> SIGINT is ctrl-C and should stay the same.
> SIGKILL will kill GNU Parallel here and now - no cleanup. And it
> cannot be caught.
> SIGTERM will make GNU Parallel kill children and clean up.
> 
> That leaves SIGHUP.
> 
> I know SIGHUP is used in some daemons to say 're-read your config',
> which is also not really the situation described in 'man 7 signal'.
> 
> I have now committed a version where SIGHUP is used. Can I ask you to
> try to make it fail/do odd things that version 20190222 does not do?
> 
> If I do not hear any reports before Thursday, I will leave it in and
> make it clear in next release that this is experimental (so that if we
> discover bad behaviour, it will be rolled back).

That's a good argument.  I didn't realize that parallel already
used USR1 and USR2.

Regards,
Gary




reply via email to

[Prev in Thread] Current Thread [Next in Thread]