bugGNU Octave - Bugs: bug #54444, Octave CLI doesn't terminate at...


bug #54444: Octave CLI doesn't terminate at sigterm until <ENTER> pressed at prompt

Submitted by:  Olaf Till <i7tiol>
Submitted on:  Sat 04 Aug 2018 04:16:28 PM UTC  
Category:  Interpreter Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Regression
Status:  Confirmed Assigned to:  None
Originator Name:  Olaf Till Open/Closed:  Open
Release:  4.4.0 Operating System:  GNU/Linux

Add a New Comment (Rich Markup)

You are not logged in

Please log in, so followups can be emailed to you.


( Jump to the original submission)

Sat 04 Jan 2020 04:30:33 AM UTC, comment #7: 

I got hit by this, too, when upgrading Octave Online to version 5.1.  Previously, I could send SIGTERM to the Octave process, and it would gracefully exit, no matter what state it was in.  Now, sending SIGTERM has no effect until the process gets some other kind of interaction.

I think this change is a bug in Octave, because the convention of SIGTERM is that the process promptly begins a graceful shutdown procedure.  If the process does not exit on SIGTERM after some amount of time, then the only other option is to send SIGKILL to the process.  **SIGTERM-wait-SIGKILL is expected to work regardless of the identity of the process**.  Since Octave does not do anything when receiving a SIGTERM, it forces agents to send SIGKILL, which doesn't allow Octave to perform any cleanup logic.

As a workaround, for the purposes of terminating an Octave process, I've changed the logic to first execute "exit" in the process, and then send SIGKILL after 10 seconds if the process hasn't gracefully exited.  This only works because I know I have an Octave process.

Shane <sffc>
Sat 09 Mar 2019 12:22:12 PM UTC, comment #6: 

FTR: Correction: The reported behaviour was not what affected the parallel package. I didn't see that Octaves signal handling is now done in an extra thread. The server of the parallel package forks and closes the parent, so this extra thread is lost. So the server has to install its own signal handling anyway (and unblock the signals).

Olaf Till <i7tiol>
Project Member
Sat 02 Mar 2019 08:02:59 PM UTC, comment #5: 

According to current libinterp/corefcn/sighandlers.cc, this seems to be due to a deliberate change -- signals for which the default action is to terminate the program are now handled by generic_sig_handler(), meaning that terminating the program is delayed until respond_to_pending_signals() is called, which again is only called by octave_quit().

I think this change is problematic. In a resting Octave instance, octave_quit() is not called. So now it is not possible any more to kill a resting Octave instance 'from outside', except with a fatal signal for which the Octave instance can't perform any clean-up actions.

The necessity for killing a resting Octave instance 'from outside', while still enabling clean-up, is given for Octave servers of the 'parallel' package. But I think it is also a generally desirable feature.

@jwe: What should be done here?

Olaf Till <i7tiol>
Project Member
Mon 04 Feb 2019 05:39:09 PM UTC, comment #4: 

Re-titling since this is not just an issue for 4.4, but also for 5.1 and the development branch.

Rik <rik5>
Project Administrator
Mon 31 Dec 2018 05:30:40 PM UTC, comment #3: 

I just re-confirmed that this issue is still present (12/31/18).

Rik <rik5>
Project Administrator
Thu 27 Sep 2018 08:36:58 PM UTC, comment #2: 

Amending title to add the part about pressing the <ENTER> key.  This also affects the development branch.

Rik <rik5>
Project Administrator
Sat 04 Aug 2018 07:03:15 PM UTC, comment #1: 

I tested Octave 3.4 and 3.6, and octave-cli 3.8 through 4.2, and all exit immediately when they receive a SIGHUP, SIGTERM, or SIGQUIT.

In Octave 4.4 (either octave-cli or octave-gui), the interpreter does exit after receiving SIGHUP, SIGTERM, or SIGQUIT, but only after pressing Enter at the interpreter prompt.

Mike Miller <mtmiller>
Project Administrator
Sat 04 Aug 2018 04:16:28 PM UTC, original submission:  

Octave-4.4(.0), started with 'octave-cli', doesn't terminate at receiving sigterm, it seems to need sigkill, which leaves files marked in Octave as temporary open. Affects the parallel package.

Olaf Till <i7tiol>
Project Member


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:

No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by sffc (Posted a comment)
  • -email is unavailable- added by i7tiol (I'm adding jwe to the CC list since his decision on how to proceed is needed.)
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by i7tiol (Submitted the item)

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.




    Follow 7 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2019-03-02 i7tiol Carbon-Copy- => Added "john w. eaton" <jwe@gnu.org>
    2019-02-04 rik5 SummaryOctave-4.4.X CLI doesn't terminate at sigterm until <ENTER> pressed at prompt => Octave CLI doesn't terminate at sigterm until <ENTER> pressed at prompt
    2018-09-28 mtmiller Carbon-CopyRemoved 80942 => -
    2018-09-27 rik5 Summaryoctave-cli of octave-4.4.0 doesn't terminate at sigterm. => Octave-4.4.X CLI doesn't terminate at sigterm until <ENTER> pressed at prompt
    2018-08-04 mtmiller CategoryNone => Interpreter
        Item GroupOther => Regression
        StatusNone => Confirmed

    Back to the top

    Powered by Savane 3.5