Any idea on how to capture closing the terminal window that my program is running in?
While I'm at it, any way to capture when the computer is shutting down but the program is still running, or if the user logs off?
If on Unix/Linux: Did you have a look at SIGTERM? This is at least the one sent to you during shutdown.
You could try the atexit() function ? (see comments)
Or look at this post here: Signals received by bash when terminal is closed
Try catching SIGTERM. Note that you can not capture SIGKILL which might be what happens during shutdown after a certain amount of time. I found this really nice post that explains some differences too.
[update] Longshot here but what about testing if std-in/out is still open and good? When the terminal dies those file descriptors should be scrapped. Disclaimer, this is a guess at best.
From my tests... the signal that my program is receiving when closing terminal is 1 or SIGHUP
Related
This question already has answers here:
how to detect Linux shutdown/reboot
(2 answers)
Closed 3 years ago.
I have an application written in C which runs as a daemon and needs to send something through RS232 when system is in shutdown or reboot state, and it needs to distinguish between these two.
So my idea is:
In my application script /etc/init.d/my_app in "stop" case of my script, I will run /sbin/runlevel command to get current runlevel:
0 - shutdown state
6 - reboot state
then I will execute some command to inform my daemon which state is it, daemon will perform communication through rs, and then will exit.
I think it should work, however it may not be the best solution, especially because my app is already running as a daemon, maybe I can receive some signal directly from system/kernel/library or through unix socket or something.
Best regards
Marek
I am not sure which signal is send to an application on system shutdown. My best guess is SIGTERM and if the application does not shutdown SIGKILL. So did you try to catch SIGTERM and properly shut down your program? There are a lot of examples on the net how to do that.
For more sophisticated process handling you can send SIGUSR1, SIGUSR2 to your application.
Is there any way my Windows program (C/C++) can receive a notification when it is being killed from Taskmgr.exe? It does not appear to receive any special Windows Messages - it just terminates.
I don't want to stop it from terminating, I just want to write a notification of some kind that it was manually terminated.
Thanks.
If it's a full windows app, you should get WM_QUIT in your message pump right before the application quits.
As MSDN states: http://msdn.microsoft.com/en-us/library/windows/desktop/ms632641(v=vs.85).aspx
This isn't posted to a window's message queue, you can only retrieve it in your main message pump.
This is only when it quits cleanly. If the process is killed, this never happens.
A way you can detect it being killed on next launch, is to have a file be created on start-up and destroyed on shutdown, If the file still exists on the next start up you know that the process was killed, but not whether it was killed due to an error or because it was killed at a users request.
If you need to know immediately when your process is killed the only way I know of is to use another process as a watchdog. If you use OpenProcess() to get a handle to the process in question, you can wait on that handle (via WaitForSingleObject or similar), and the handle will be signalled when the process terminates. You'll need to do some coordination with the target process in order to track whether the shutdown was clean or forcible.
I am writing daemon application for Debian Sid. It works perfectly most of the times, but dies silently after i put my laptop to suspend (or hibernate). So i have a couple of questions:
What should I Google for solutions?
Maybe, you have any ideas what is going on?
Try strace-ing the daemon to see what is the reason it dies silently. Generally, suspend/hibernate alone should have no effect on user processes.
Daemon's loop was on blocking read call, and suspend (hibernate) interrupts it. So, should check errnos more accurately.
Fixed by adding:
if ( errno == EINTR ) continue;
I have a coded a program in C for linux. At the moment I am using ubuntu upstart to run as a background service.
I want to be able to have the program gracefully shutdown when commanded instead of just being killed off. Can someone please point me to the functions used to receive such a command?
(edit: can't answer own post but it seems I am meant to use signal.h signal function to put callbacks on SIGTERM and SIGKILL).
You want to use sigaction(2) to define a handler to be run when SIGTERM is caught.
We have a small daemon application written in C for a couple of various UNIX platforms (this problem is happening in SunOS 5.10), that basically just opens up a serial port and then listens for information to come in via said port.
In this particular instance, the daemon appears to read a single transmission (like a file's worth of data) sent over via the serial port, then it receives a SIGINT. This happens every time. Other customers use this setup very similarly without receiving the SIGINT. Quite obviously, the users are NOT pressing Ctrl-C. We have a relatively simple signal handler in place, so we definitely know that that is what is happening.
What else could possibly be causing this? Googling around and looking through the questions here, I couldn't find much explanation as to other things that could cause a SIGINT. I also looked through the code and found no calls to raise() and only a single call to kill(pid, 0) which wouldn't send a SIGINT anyway.
Any thoughts or insight would definitely be appreciated.
If you do not want the serial port to become the controlling terminal for the process, open it using the open flag O_NOCTTY. If it is the controlling terminal, data from the serial port may be interpreted as an interrupt or other special character.
You didn't say how your signal handler is attached, but if you're able to attach it using sigaction(2) so as to get a siginfo_t then it looks like that would include the pid that sent the signal (si_pid).
I found an interesting blog post about debugging a problem with similar symptoms. While I doubt it's the same issue, it's got some very useful debugging tips for tracing the origin of signals.