[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 <garyjohn@spocom.com> 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