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]
--
_______________________________________________
Lazarus mailing list
[email protected]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
