I'm quite new to solaris. I have this problem thats bugging me for sometime now.
I start a process in solaris as
nohup <binary>
I do this so that my process would not get SIGHUP, the process will not terminate even after I exit from my shell.
I tested this out, by exitting from my shell.
It works as expected,the process still runs.
Problem:
When my process is idle for too long, I see the following line in dmesg..
[ID 702911 auth.error] [29069] Run idle timeout reached (32400 seconds)
Then my process gets a SIGHUP, and terminates.
I'm struggling with the following questions...
Which process writes this timeout message in dmesg? How can I find it out?
How come my process still get a SIGHUP despite starting with nohup? Are there any other means for a process to get a HUP signal?
Note: I tried kill -1 <my process id> . Then my process terminates because of the HUP signal.
Can anyone help me on this?
Related
My SSH session was terminated abruptly and gdb was running. When I try to attach gdb again to the same process, I get:
ptrace: Operation not permitted.
The ttys:
[root#xxx ~]# who
root pts/0 2017-11-27 03:57 (10.193.26.12)
root pts/1 2017-11-27 04:40 (10.193.26.12)
Question: Which signal should I send to GDB for it to quit gracefully? Are there other ways to solve it?
kill -HUP $gdbpid did the trick for me.
This also kills the inferior when it was invoked by the victim GDB.
However, I do not know whether it also kills the inferior when GDB has been attached to the inferior.
If the parent shell of GDB is still running, then you can attempt to close the pseudo terminal. I usually do it like this:
echo > /dev/pts/0
This forces the SSH parent process to exchange data with the peer. But since the network connection it is gone (as in "the terminal has hung up"), it goes through its shutdown procedure, which includes sending SIGHUP to the process group. The net effect is the same.
I have searched several questions on stackoverflow about debugging SIGTERM, but have not get the information I needed. Perhaps, I am still new to this issue.
My program terminated with the SIGTERM signal without core dump and I donot know how to track this down. My Question is, what is the general way of debugging this issue in GDB?
Thanks.
Although SIGTERM can be sent by the kernel in a few cases, it's almost always sent by another user process. If you run your program under gdb, then when it receives a SIGTERM it will become paused. You can then get some info about the signal by looking at the $_siginfo structure:
(gdb) print $_siginfo._sifields._kill
$2 = {si_pid = 3926, si_uid = 1001}
This is on Linux. It means that pid 3926 sent the signal, and the userid who sent it is 1001.
My program terminated with the SIGTERM signal without core dump
It is expected that if someone sends your program a SIGTERM, then no core dump is produced.
and I donot know how to track this down.
You need to figure out where that SIGTERM is coming from. Someone sends it your program, and the key question is who.
Usually SIGTERM is sent when either you type Control-C in the terminal in which you started the program (correction, that would send SIGINT, not SIGTERM), or you type kill <pid> in some other terminal.
A very odd one: I have a Qt 4 embedded app that runs on framebuffer, it normally runs from inittab as the only UI on the box. There is an option to put the machine to sleep - I do the normal thing and open /sys/power/state, write "mem" and close it (using QFile). Very straight forward and it works fine EXCEPT the first time the app runs after booting. If it sleeps then it receives SIGUSR2 and just hangs forever with a blank screen. The hang occurs after resume.
But, if I manually kill it and run it again .. sleep works fine again. Note that it must do the failed sleep attempt and be killed - whereafter all is peachy every time it runs, SIGUSR2 never shows up again.
I have already tried to trap the signal - doesn't trap. No idea why - except that I know that pthreads uses SIGUSR2 ..
Stumped. Ideas? Clues?
[edit] I found that if I fork() and write to /sys/power/state in the child and exit it sort of solves the problem, but it doesn't solve the mystery..
[edit 2] I subsequently found that in fact the child is still hanging when the machine is shut down (causing it to hang forever without shutting down..), although the ugly hack just mentioned did fix the hang coming out of suspend - I have not figured out what is happening but finally solved it by just using a script/daemon: in a while loop it checks a file in /tmp for an action and either halts or suspends and restarts the app afterwards .. not pretty but it works.
And still the mystery of the SIGUSR2 hang remains ..
Assume the daemon server is running on a specific process_id
So if I give command kill process_id from terminal, then the daemon server process exits.
How can I handle this signal.
Also what are the other signals I need to take care of, for running the daemon server uninterrupted ?
EDIT : Operating system Ubuntu
You can block almost all signals, with the notable exception of SIGKILL.
By default the kill command sends SIGTERM, which you can block.
Read about the sigaction system call to learn how to block signals.
The simple interface for signal is:
void (*singnal(int signo, void(*func)(int)))(int);
It is a function registering a processing function for a specific signal, indentified by a signal number.
I want my program to react on being killed by the 'killall myApplication' command.
So that it can save something and then terminate.
I know this must be done by signal handling but I am not sure which Singal it gets when being killed.
killall or killall -9? Because -9 would mean SIGKILL, which cannot be handled nor masked (your process would be terminated right away in the scheduler, without it having any notion that any signal was sent to it).
Without -9, it would be SIGTERM, which can be handled. Have a look at man signal.