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

[Mark Morgan Lloyd]

waldo kitty wrote:
> On 2/16/2013 12:43, Michael Van Canneyt wrote:
>>
>>
>> On Sat, 16 Feb 2013, waldo kitty wrote:
>>
>>> On 2/16/2013 08:30, Hans-Peter Diettrich wrote:
>>>> Procedures even may be different for Linux and Windows, depending on 
>>>> the
>>>> signal/message types. Even if a program can ignore SIGTERM, can it 
>>>> also inform
>>>> the system that it doesn't *want* to close? On Windows a program can 
>>>> stop an
>>>> shutdown, maybe not on other platforms.
>>>
>>> i have exactly this problem to deal with on *nix... my app needs to 
>>> be allowed
>>> to complete its shutdown closeout procedures or there are problems on 
>>> the next
>>> boot when it is started up... on shutdown, app managed data is 
>>> removed from a
>>> living data file to another file for restoration on startup... this 
>>> takes
>>> longer than 5 seconds and it hurts at times when the system sigkills 
>>> the app :/
>>
>> Why not just rename the file and do the cleanup on startup ?
> 
> because not all the data in the file is managed by the app... some of 
> the data is managed by human hands... some of it may be managed by 
> another app... all three, human, other app, and my app all share the 
> same data file because it is tied into the system's other management 
> controls...
> 
> FWIW: the apps are firewall rules management apps and the data file is 
> used by the GUI to show the firewall rules in place... back end code 
> uses the system's existing iptables code to add, remove and edit the 
> firewall rules... when an app shuts down, it removes its rules from the 
> list and from the iptables... in the end, the only permanent rules are 
> those that the human placed...
> 
> i was hoping to find a solution so that the app didn't have to be 
> rewritten to use another iptables section, data file and a whole other 
> set of GUI management screens...

Mixing the source of rules in iptables can be bad news, particularly if 
some of the IP addresses are dynamic. BTDT. It's compounded by the API's 
reluctance to issue an unambiguous token for each rule, which can either 
be used for revocation at any point in the future or be shown to be no 
longer relevant.

Having a separate table would probably be the best way, provided that 
you can find some way of making sure that it stays hooked into the 
dataflow. Otherwise what I'd suggest- with thanks to the input of Sven 
et al.- is that you record rules that you add when you add them, and 
always check at program startup that there are no relicts.

If the OS decides to send your program a term- OK, you can hook that 
providing that the user doesn't lose patience. If it sends a term 
followed by a kill- it probably has good reasons, e.g. the user is 
shutting the entire system down which will obviously flush the tables 
anyway. But there are other cases, e.g. where a UPS can signal a 
powerfail but then change its mind.

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

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