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

[Mark Morgan Lloyd]

Sven Barth wrote:
> On 16.02.2013 10:54, Mark Morgan Lloyd wrote:
>>>> 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.
> 
> An important note about signal handlers: don't do anything complicated 
> in them. Maybe just set a flag (e.g. "SignalTerminated := True") and 
> handle that in your application loop once control returned. Signals are 
> executed from a different stack space and a different context and thus 
> showing e.g. dialogs from within the handler is a bad idea(TM).

Yes, agreed. Is an Application.QueueAsyncCall() safe?

>> 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.
>>
> 
> The reason for this "first TERM then KILL" approach is that an 
> application could either hang (and thus not respond correctly to TERM if 
> it has hooked it) or it could just ignore the TERM. So on shutdown the 
> init system normally sends a TERM to all processes first and gives them 
> a chance to cleanup any data they might want to save and then those 
> applications that are left are killed.

Yes, but I also found it /explicitly/ in a script (Slackware rc6.d or 
somesuch).

> Windows does a similar thing by the way. On shutdown (or logoff) all 
> applications are notified that the user session terminates and are given 
> a chance to cleanup. Then the "application does not respond" dialog is 
> shown (in versions pre Vista a dialog with a "count down progress bar" 
> is shown in versions from Vista on a "these applications hinder 
> shutdown/logoff" overlay is shown). If the applications did not 
> terminate till then each remaining application is killed using 
> ProcessTerminate which can not be caught by the application either.

I've found Windows' UPS API to be the most reliable way of shutting apps 
down fast when rebooting a system is more important than having each 
program do its housekeeping.

>> 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).
>>
> 
> This is why I linked the "asking for a security hole" blog entry in the 
> other thread. World writable files are simply not good. You get only 
> problems with them.

I agree, but there's a big difference between "world" and "multiple 
programs running in the context of the same user".

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

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