We could just have Octave call exit in the signal handler immediately when the TERM signal arrives, but that would skip the usual shutdown procedure and that doesn't seem like the best behavior.  So, we just have the signal handler set a global variable and respond to that when it is safe to do so (at a place where octave_quit is called).  So typically Octave does not respond to signals while it is waiting for input or for a library function to return (see, for example, bug #56828 or bug #37795).  It only works with readline because the readline function that waits for user input also allows us to periodically check for events.

But, presumably Web users of the Octave Online Server do not have a way of sending an IPC signal to the running process.

Verified fix.  Changing Status to "In Progress" to reflect the fact that this may need to be re-visited if we want to get the last 10% of cases where readline is not being used.

I verified that the patch does what it says.  Most of the time I think readline is compiled in so this will certainly help on a lot of installations.  It is probably worth applying as it would get rid of 90% of complaints.

I would still leave this bug open though in case we can find a universal fix.

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.

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?

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

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.