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

Sven Barth pascaldragon at googlemail.com
Sat Feb 16 11:26:58 CET 2013


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).

>
> 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.

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.

> 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.

Regards,
Sven




More information about the Lazarus mailing list