logout stuck - exit only with Ctrl+C - centos7

When I logout from Linux server running CentOS7.
It stuck.
I run the ps command to see which processes are running, I saw:
dbus-launch --autolaunch XXX --binary-syntax --close-stderr
/usr/bin/dbus-daemon --fork --print-pid 6 --print-address 8 --session
/usr/bin/dbus-daemon --config-file=/usr/share/defaults/at-spi2/accessibility.conf --nofork --print-address 3
/usr/libexec/at-spi2-registryd --use-gnome-session
After it was stuck for a long time, I press ^C.
It cause a the logout to finish (I logout from the server) and the above processes killed.
Why it happen. What can I do to solve it?
Thanks.

I had / full 100%.
After I clean it the problem solved

Related

Daphne multi process exit working when running with supervisord. Set 4 process but only 1 keeps running

I've Daphne working with Supervisord.
Config is set to have 4 simultaneous processes but it happens 3 of them exit without explanation and only one keeps running properly.
I do have 2 CPUs.
Supervisord config is:
The output is:
Then I tried changing the File descriptor:
The output still show only one process
Then I tried some variations:
1 - Change the file descriptor to --fd 10
2 - Replace --fd 10 with --endpoint fd:fileno=0
Same luck... or lack of luck.
Am I missing something? Why I just can't have 4th processes running all time? Does it make a difference in performance between 1 and 4 for a small app?
I found that Daphne fails silently when multi process are tried to be open on the same port and only one of them keeps alive.
https://github.com/django/daphne/issues/187
So I just duplicated the config and changed the ports and now all my processes are running fine.
As you can see no one exits now:

Quiting GDB that was started in another terminal gracefully

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.

Killing a daemon process through cron job/runnit

I have a python file which starts 2 threads - 1 is daemon process 2 is to do other stuff. Now what I want is to check if my 2 thread is stopped then 1 one also should stop. I was suggested to do so by cron job/runnit.. I am completely new to these so can you please help me achieve the goal
Thanks
The best way out is to create this daemon as a child thread so it automatically gets killed when parent process is killed

Process terminates with HUP signal despite starting with nohup

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?

Strangeness with SIGUSR2 and sleep (Qt 4 embedded)

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