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

Sven Barth pascaldragon at googlemail.com
Sat Feb 16 12:41:15 CET 2013


On 16.02.2013 11:46, Mark Morgan Lloyd wrote:
> 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?
>

It could be that this also allocates memory to append the queued call, 
so this might also be probematic...

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

If I'd need to guess than I'd say that this is the script executed by 
Slackware's init process if run level is 6.

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

If shutting down is more important than house keeping on a Unix system 
than you just need to send a SIGKILL to each process and then initiate 
shutdown.

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

I consider this the same, because you can't guarantee the write order of 
the programs and AFAIK TIniFile writes the complete file and not only a 
part of it.

Regards,
Sven




More information about the Lazarus mailing list