[Lazarus] Finding out how a program's being terminated

[Mark Morgan Lloyd]

Sven Barth wrote:
> On 16.02.2013 09:22, Mark Morgan Lloyd wrote:
>> On unix (Linux, Solaris etc.) is it possible to determine how a program
>> written using Lazarus is being terminated? Specifically, is there any
>> different behaviour when a  kill  signal arrives from a routine  term
>> signal, and is a title-bar close button simply a  term  signal?
> 
> SIGTERM can be caught and handled by application using a signal handler, 
> so it can do some cleanup or even ignore the signal completely.
> SIGKILL can not be caught and will directly kill the process without any 
> chance for further progressing.
> 
> And a title bar close button does normally invoke a event of the used 
> GUI toolkit (in case of Windows it would be the message "WM_CLOSE", I 
> don't know the event names of GTK and Qt :) ) and not send a SIGTERM.

Thanks, I'll have a play with this later.

>> I'm trying to think ahead and plan for what a bunch of related (but not
>> necessarily tightly-coupled) programs do if there's e.g. a UPS shutdown
>> notification which sends a  kill  signal. Specifically, if there's a
>> routine  term  it is probably appropriate to save the current window
>> sizes etc. while if there's a  kill  because the UPS is trying to shut
>> everything down fast it's probably safest to assume that there's a risk
>> of multiple programs trying to access common files simultaneously.
>>
> 
> If there is a SIGKILL you can't do anything in your program and you 
> won't be notified that you even got that signal.

OK, so a hypothetical program with term hooked makes sure it behaves 
like a window manager close. If multiple related programs are shut down 
manually by the user (WM or term signal) they can put up a dialogue 
asking whether the state is to be saved, and it's reasonable (although 
not strictly correct) to assume that the user won't OK all of these 
simultaneously. Or if they are shut down by a kill signal they 
presumably don't do OnCloseQuery (or whatever- working from memory) and 
presumably don't run finalization blocks.

The thing that initially got me jittery was a shutdown script (from an 
elderly Slackware) that first signalled term to everything, waited five 
seconds and signalled kill. But if the term resulted in a dialogue 
asking whether the state is to be saved then presumably the kill would 
never OK this.

So I think this leaves two cautionary cases which arise because a term 
signal can be sent to multiple programs simultaneously (e.g. by the 
killall5 program). The first is that a shutdown caused by a term signal 
should not attempt to e.g. save state to a .ini file if there's a risk 
that that file is shared without waiting for manual confirmation. The 
second is that if a shutdown presents a dialogue box this should not 
have a user-friendly "I'll save your data after five seconds" default, 
unless it's absolutely certain that the files won't be shared (this 
might be acceptable for a WM close event, but definitely not for a signal).

-- 
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]