My understanding is that Linux sends a SIGTERM notification to all applications before shutting down. I would like to catch the SIGTERM notification so that I can close any open files and perform other application cleanup. Currently my application has no idea that it is about to be killed when Linux shuts down which means I can’t shutdown my application gracefully.
I’d like to catch the SIGTERM notification without the use of add-on libraries if possible since my application is open source and therefore shouldn’t rely on commercial add-ons.
That is usually not a problem.
You can put the plugin in the requirements list for the project beside the Xojo version you need.
And keep license key in an external module, which you don’t upload to the repository.
Well, I lloked at the sample code pointed to by @Jürg_Otter and @Greg_O_Lone and was able to install a SIGTERM handler (using the ‘sigaction’ system call) in my desktop application. Thanks to both of you.
But… (why is there always a ‘but’) It appears that when Raspbian is shutting down, my application is terminated without receiving a SIGTERM. So now I’m wondering if desktop applications use a different mechanism for shutting down?
I can issue a "kill " command and my application receives the SIGTERM and I set a global variable which is monitored by a timer with a one second interval. In the timer’s action event I display a a message box which asks to quit the application (yes/no). So I know beyond any doubt that I am able to receive and process a SIGTERM. But when my application is terminated because the system is rebooting or shutting down no SIGTERM is received.
So, does anyone know if GUI applications are treated differently than Console applications when it is time to shut them down?
I think the more relevant answer is that once you receive a signal, you only have a limited amount of time in which to shut down your app. Showing a message dialog may not be allowed at this point.
You should probably also try catching SIGKILL although if your app isn’t running as root that may not work either.
The application I described was simply a test rig for proof of concept. In actual use I would not interact with the user at all. I would simply close all open files and release other system resources.
According to everything I’ve read, SIGKILL is not trappable. This makes sense to me as SIGKILL is the last resort method for getting rid of a misbehaving application. A misbehaving application should never be able to decline being shut down.
I find it amazing that giving a desktop application an opportunity to clean up before killing it seems to be a foreign concept. In Windows there is a well defined protocol for application termination that avoids the possibility of corrupted files during system shutdown or reboot. Linux must have a similar mechanism for GUI applications?
well let me ask this question though… if it’s not going to interact with the user why not make it a console app and use SystemD to start/stop it. then you can specify what kind of signals it’d be getting.
If the user needs to interact with it, you make a separate app for that and interact through and IPC socket, sqlite database, text file or something else.
I don’t disagree with this idea. But let me counter with another question: What if I was building a something like a Word Processor application? Would it be acceptable for the system to shut down or reboot, killing my application and possibly leaving the user’s work corrupted or otherwise lost without giving the user an opportunity to save his work? This doesn’t seem like an unreasonable expectation. But then Linux isn’t Windows so this may not be something that fits well with the Linux developer’s mind-set?
I will look into breaking this segment of my application off into a console app. I just need to educate myself in how to control and communicate with it from my main application.