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.
Related
I am working to port a C/Fortran package that was written for POSIX systems to Windows. Most of the Fortran part of the software runs mathematical calculations. The C codes act as interfaces between Fortran and the system. The code is fully console-based and does not have a GUI.
The software is parallelised with MPI, i.e. after launch it runs multiple processes - one master process and several child processes.
Now, one of the hurdles I have faced with porting is the C code that deals with signal. The master process and child processes each have their signal handlers. The way the signal handling is implemented is that, when the master process receives the SIGTERM or SIGSEGV, it sends those to the child processes. In POSIX, that is implemented by kill(pid, SIGTERM). The signal handler of the child processes then interact with the Fortran part to gracefully bring the program to an exit.
What would be the best strategy to port this behaviour to Windows? I am not much familiar with Fortran so I would leave the fortran part untouched if I can. The only thing I have to ensure is that somehow the master process communicates with child processes via their PID, then I have enough to start writing code.
I have asked questions about an alternative to kill() on Windows, and it seems like there is no easy alternative. Please add an answer even if it means I have to modify a lot of code. The C signal code can be seen in another question I asked about this here.
(Please don't mention cygwin or WSL. Cygwin fails to compile it, and I need to run it from Windows, WSL binaries don't work outside of it)
In our code base we have a part of software that allows to run an arbitrary amount of external programs and monitor their exit codes via the use of fork() and the installation of a SIGCHLD handler. In the unit test cases this piece of software works fine.
However the process that is running this fork "server" is also running a bunch of software modules in several threads. Unfortunately one some parts of this (older) software are using popen() which seems to need to use its own SIGCHLD handler. The result we see is that the program will fail on the call to pclose() with the errno ECHILD.
Is there any way to use a SIGCHLD handler and a call to popen/pclose in parallel?
After fork(), signal handlers are inherited. So perhaps you should reset them to their defaults between fork() and exec(), by using signal() with SIG_DFL in the first child process, before you invoke the legacy software.
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
I have designed a message passing interface in c which is used to provide communication between different processes running in my system. This interface creates 10-12 threads for its purpose and use TCP sockets to provide communication.
It is working fine but sometimes it receives signal SIGTERM. Can anyone please tell me why is it receiving this signal.
If a human isn't killing your process, then the kernel is.
This can happen when a machine is trying to save itself from drowning (you've used up all the memory/swap/resources). Might want to look at what's going on on that system when your process is running.
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.