Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / lazarus / 2013-02

Finding out how a program's being terminated

22 messages · 8 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Mark Morgan Lloyd

On unix (Linux, Solaris etc.) is it possible to determine how a program written using Lazarus is being terminated? Specifically, is there any different behaviour when a kill signal arrives from a routine term signal, and is a title-bar close button simply a term signal?

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.

Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues]

Reply by email

Sven Barth
to Mark Morgan Lloyd
Mark Morgan Lloyd wrote
On unix (Linux, Solaris etc.) is it possible to determine how a program written using Lazarus is being terminated? Specifically, is there any different behaviour when a kill signal arrives from a routine term signal, and is a title-bar close button simply a term signal?

SIGTERM can be caught and handled by application using a signal handler, so it can do some cleanup or even ignore the signal completely. SIGKILL can not be caught and will directly kill the process without any chance for further progressing.

And a title bar close button does normally invoke a event of the used GUI toolkit (in case of Windows it would be the message "WM_CLOSE", I don't know the event names of GTK and Qt :) ) and not send a SIGTERM.

Show quoted text 9 lines
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.

Regards,
Sven

Reply by email

Mark Morgan Lloyd
to Sven Barth
Sven Barth wrote 14 lines
On 16.02.2013 09:22, Mark Morgan Lloyd wrote: > On unix (Linux, Solaris etc.) is it possible to determine how a program > written using Lazarus is being terminated? Specifically, is there any > different behaviour when a kill signal arrives from a routine term > signal, and is a title-bar close button simply a term signal? SIGTERM can be caught and handled by application using a signal handler, so it can do some cleanup or even ignore the signal completely. SIGKILL can not be caught and will directly kill the process without any chance for further progressing. And a title bar close button does normally invoke a event of the used GUI toolkit (in case of Windows it would be the message "WM_CLOSE", I don't know the event names of GTK and Qt :) ) and not send a SIGTERM.

Thanks, I'll have a play with this later.

Show quoted text 11 lines
> 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.

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.

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

Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues]

Reply by email

Ludo Brands
to Mark Morgan Lloyd
Mark Morgan Lloyd wrote 10 lines
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.

I wouldn't count on that. See below.

Show quoted text 6 lines
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.

That is afaik still the default behaviour of init. You have 5 secs between SIGTERM and SIGKILL. Are all users going to click OK in 5 secs? Also watch out that a signal handler runs asynchronously. You aren't allowed to do a lot in a signal handler and should not use non-reentrant functions such as malloc. Pop ups in signal handlers are not a good idea.

Show quoted text 10 lines
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).

What about splitting configuration in a global read-only part and a local read-write session part? As mentioned before INI files are no good for shared read/write configuration saving.

Ludo

Reply by email

Sven Barth
to Mark Morgan Lloyd: Thanks, I'll have a play with this later. OK, so a hypothetical program with term hooked…
Mark Morgan Lloyd wrote 20 lines
>> 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).

Show quoted text 7 lines
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.

Show quoted text 10 lines
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

Reply by email

Sven Barth
to Ludo Brands: I wouldn't count on that. See below. That is afaik still the default behaviour of init.…
Show quoted text 12 lines
> 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. > That is afaik still the default behaviour of init. You have 5 secs between SIGTERM and SIGKILL. Are all users going to click OK in 5 secs? Also watch out that a signal handler runs asynchronously. You aren't allowed to do a lot in a signal handler and should not use non-reentrant functions such as malloc. Pop ups in signal handlers are not a good idea.

Additionally the X11 server might already be shutdown itself. E.g. on my ArchLinux system the X11 server is shutdown as one of the first (which takes all GUI applications with it without asking) and only then all remaining processes are terminated using SIGTERM and afterwards SIGKILL.

Regards,
Sven

Reply by email

Mark Morgan Lloyd
to Sven Barth: An important note about signal handlers: don't do anything complicated in them. Maybe…
Sven Barth wrote 27 lines
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?

Show quoted text 13 lines
> 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).

Show quoted text 8 lines
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.

Show quoted text 15 lines
> 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]

Reply by email

Mark Morgan Lloyd
to Ludo Brands: I wouldn't count on that. See below. That is afaik still the default behaviour of init.…
Ludo Brands wrote 23 lines
On 02/16/2013 10:54 AM, Mark Morgan Lloyd wrote: > 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. > I wouldn't count on that. See below. > 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. > That is afaik still the default behaviour of init. You have 5 secs between SIGTERM and SIGKILL. Are all users going to click OK in 5 secs? Also watch out that a signal handler runs asynchronously. You aren't allowed to do a lot in a signal handler and should not use non-reentrant functions such as malloc. Pop ups in signal handlers are not a good idea.

But as I've said to Sven, in my case I'm specifically interested in the single-user case and it will take a user a finite time to move between dialogue boxes (which is probably a good argument for instead using modal forms instead of dialogue boxes in this role, and to make sure they're spread over the screen).

Show quoted text 13 lines
> 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). > What about splitting configuration in a global read-only part and a local read-write session part? As mentioned before INI files are no good for shared read/write configuration saving.

Agreed. Any shared part should only be written during the start of the program run, never in response to a signal or shutdown event.

Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues]

Reply by email

Sven Barth
to Mark Morgan Lloyd: Yes, agreed. Is an Application.QueueAsyncCall() safe? Yes, but I also found it…
Mark Morgan Lloyd wrote 34 lines
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...

Show quoted text 17 lines
>> 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.

Show quoted text 13 lines
> 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.

Show quoted text 19 lines
>> 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

Reply by email

Mark Morgan Lloyd
to Sven Barth
Sven Barth wrote 10 lines
>> 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...

Thanks, noted.

Show quoted text 13 lines
>> 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.

Yes, but I'm making the point that at least on that system it's not something implicit to init. Debian looks like it does it differently, but I'd imagine that the end result is pretty much the same.

Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues]

Reply by email

Ludo Brands
to Mark Morgan Lloyd
Show quoted text 8 lines
> > 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. Yes, but I'm making the point that at least on that system it's not something implicit to init. Debian looks like it does it differently, but I'd imagine that the end result is pretty much the same.

Debian has shuffled the names a bit but the principle is the same. /etc/init.d/rc calls eventually /etc/init.d/sendsigs and in that script you'll find
killall5 -15 $OMITPIDS # SIGTERM
followed a little later by
killall5 -9 $OMITPIDS # SIGKILL

Ludo

Reply by email

Hans-Peter Diettrich
to Mark Morgan Lloyd: Thanks, I'll have a play with this later. OK, so a hypothetical program with term hooked…
Show quoted text 15 lines
Sven Barth wrote: > On 16.02.2013 09:22, Mark Morgan Lloyd wrote: >> On unix (Linux, Solaris etc.) is it possible to determine how a program >> written using Lazarus is being terminated? Specifically, is there any >> different behaviour when a kill signal arrives from a routine term >> signal, and is a title-bar close button simply a term signal? > > SIGTERM can be caught and handled by application using a signal > handler, so it can do some cleanup or even ignore the signal completely. > SIGKILL can not be caught and will directly kill the process without > any chance for further progressing. > > And a title bar close button does normally invoke a event of the used > GUI toolkit (in case of Windows it would be the message "WM_CLOSE", I > don't know the event names of GTK and Qt :) ) and not send a SIGTERM.

The handling of the close button, menu entry etc. GUI element IMO can be unified into a CloseQuery, possibly followed by a Close - provided that the program/library can determine that it is the result of a GUI action, affecting only a specific instance.

Show quoted text 9 lines
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).

Compromise: try saving all data, skipping write-locked files.

I'm not sure how to deal with unsaved data in general. A program can ask "Sure to exit?" first, then determine whether unsaved data exist, ask "Exit without saving?", before really terminating. But it also can decide to exit immediately, if no data deserve saving, or to save before asking "Sure to exit?".

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.

DoDi

Reply by email

waldo kitty
to Sven Barth: An important note about signal handlers: don't do anything complicated in them. Maybe…
Sven Barth wrote 5 lines
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.

what can be done if it takes more than 5 seconds to perform the cleanup and closeout process when sigterm is received??

Reply by email

waldo kitty
to Hans-Peter Diettrich: The handling of the close button, menu entry etc. GUI element IMO can be unified into a…
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 :/

Reply by email

Michael Van Canneyt
to waldo kitty
waldo kitty wrote 14 lines
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 ?

Michael.

Reply by email

Sven Barth
to waldo kitty: what can be done if it takes more than 5 seconds to perform the cleanup and closeout…
waldo kitty wrote 13 lines
On 2/16/2013 05:26, Sven Barth wrote: > 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. what can be done if it takes more than 5 seconds to perform the cleanup and closeout process when sigterm is received??

Nothing. And that's good, because I definitely dislike it when the computer hangs in shutting down (especially if that computer is a laptop with a spinning harddrive and I plan to move it rapidly after shutdown).

Regards,
Sven

Reply by email

waldo kitty
to Michael Van Canneyt: Why not just rename the file and do the cleanup on startup ? Michael.
Michael Van Canneyt wrote 17 lines
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...

Reply by email

Henry Vermaak
to Michael Van Canneyt: Why not just rename the file and do the cleanup on startup ? Michael.
Michael Van Canneyt wrote 18 lines
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 ?

Some editors do it like this, e.g. if I edit a file in vim and then kill it from another terminal:

hcv at hcv-q45:~$ vim test.txt
Vim: Caught deadly signal TERM
Vim: preserving files...
Vim: Finished.

The next time I try to edit that file, it asks me if I want to recover it. This has saved me more than once :)

Henry

Reply by email

Mark Morgan Lloyd
to waldo kitty: because not all the data in the file is managed by the app... some of the data is managed…
waldo kitty wrote 43 lines
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]

Reply by email

Mark Morgan Lloyd
to waldo kitty: i have exactly this problem to deal with on *nix... my app needs to be allowed to…
waldo kitty wrote 14 lines
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/ is it taking longer than five seconds? Are you using the iptables program to manipulate individual rules, or going directly to the API?

Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues]

Reply by email

waldo kitty
to Mark Morgan Lloyd
Mark Morgan Lloyd wrote 15 lines
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/ is it taking longer than five seconds? Are you using the iptables program to manipulate individual rules, or going directly to the API?

because there may be several thousand rules to save, for one thing... other than that, i can't go into any more of the specifics because it is too far afield from pascal and/or lazarus... i was only interested in if there was a solution to delay shutdown until a process has actually completed its shutdown tasks...

Reply by email