Open a terminal
Open the second terminal
Excute command "$ xlogo" in the sceond terminal
Find out the parent process of xlogo in the first terminal
(I find out that "bash" is the parent process)
Terminate the parent process of xlogo in the first terminal
(Command:$ kill -9 PID of parent process)
At this moment, "xlogo" and the second terminal are gone.
Open the third terminal.
Excute the command "$ xlogo &" in the third terminal (Let xlogo running in the background)
Teminate the parent process of xlogo in the first
terminal
(Command:$ kill -9 PID of parent process)
At this moment, "xlogo" still alive, but the third terminal is gone.
By excuting the command "$ pstree", I find that "xlogo" belongs to "systemd".
Questions:
a) Why "xlogo" was killed with its parent process when "xlogo" ran in the foreground?
b) Why "xlogo" still alive and didn't die with its parent process when "xlogo" ran in the background?
I am searching for a long time on the net. But get nothing.
Could anyone try to give some ideas on how to explain this?
thx
Related
I wanna stop Node server on linux but when I try to stop it, It automatically starts with new PID how can I stop this completely. Here you can see I tried to stop Nginx and Node.
How can I check if it is a linux zombie process? If yes then How can I kill it? otherwise
I have tried tried these commands.
kill pid
Kill -9 pid
killall node <<command not working
This was spawn by it's parent process, I search out parent process after killing that this stop as well.
I am aware that adding a '&' in the end makes it run as a background but does it also mean that it runs as a daemon?
Like:
celery -A project worker -l info &
celery -A project worker -l info --detach
I am sure that the first one runs in a background however the second as stated in the document runs in the background as a daemon.
I would love to know the main difference of the commands above
They are different!
"&" version is background , but not run as daemon, daemon process will detach with terminal.
in C language ,daemon can write in code :
fork()
setsid()
close(0) /* and /dev/null as fd 0, 1 and 2 */
close(1)
close(2)
fork()
This ensures that the process is no longer in the same process group as the terminal and thus won't be killed together with it. The IO redirection is to make output not appear on the terminal.(see:https://unix.stackexchange.com/questions/56495/whats-the-difference-between-running-a-program-as-a-daemon-and-forking-it-into)
a daemon make it to be in its own session, not be attached to a terminal, not have any file descriptor inherited from the parent open to anything, not have a parent caring for you (other than init) have the current directory in / so as not to prevent a umount... while "&" version do not
Yes the process will be ran as a daemon, or background process; they both do the same thing.
You can verify this by looking at the opt parser in the source code (if you really want to verify this):
. cmdoption:: --detach
Detach and run in the background as a daemon.
https://github.com/celery/celery/blob/d59518f5fb68957b2d179aa572af6f58cd02de40/celery/bin/beat.py#L12
https://github.com/celery/celery/blob/d59518f5fb68957b2d179aa572af6f58cd02de40/celery/platforms.py#L365
Ultimately, the code below is what detaches it in the DaemonContext. Notice the fork and exit calls:
def _detach(self):
if os.fork() == 0: # first child
os.setsid() # create new session
if os.fork() > 0: # pragma: no cover
# second child
os._exit(0)
else:
os._exit(0)
return self
Not really. The process started with & runs in the background, but is attached to the shell that started it, and the process output goes to the terminal.
Meaning, if the shell dies or is killed (or the terminal is closed), that process will be sent a HUG signal and will die as well (if it doesn't catch it, or if its output goes to the terminal).
The command nohup detaches a process (command) from the shell and redirects its I/O, and prevents it from dying when the parent process (shell) dies.
Example:
You can see that by opening two terminals. In one run
sleep 500 &
in the other one run ps -ef to see the list of processes, and near the bottom something like
me 1234 1201 ... sleep 500
^ ^
process id parent process (shell)
close the terminal in which sleep sleeps in the background, and then do a ps -ef again, the sleep process is gone.
A daemon job is usually started by the system (its owner may be changed to a regular user) by upstart or init.
So how can I close the terminal where the process is in with killall.
I have tried this:
In 1st terminal:
killall node
In 2nd terminal:
Ready
Terminated
But I want only the 2nd terminal to close after the node is killed.
You can use the -t option:
killall -t $(tty)
will call all processes started from the terminal session (even with nohup), including the shell. So, your terminal will get closed.
You need to also kill the process which runs the terminal, which is usually the parent process of the node process.
The question How do I get the parent process ID of a given child process? is a good place to start. You can find the PIDs of the node processes via How to find the Process ID of a running terminal program.
I can see a process with ps, but it does not appear in "tasklist" (or windows taskmanager).
PID PPID PGID WINPID TTY UID STIME COMMAND
15356 1 16284 10496 pty2 1001 12:59:42 /cygdrive/c/Users/Application1
I openned terminal as Administrator. I have tried using PID, WINPID and PGID as xxxx in:
kill -9 xxxx
/bin/kill -f xxxx
taskkill /pid xxxx
None of them work.
ppid 1, seems to be a child process of something. in the worst case kill the "father"-process.
Is your taskmanger started as Admin? view of all user processes activated?
Did you try to kill it with alternative taskmanagers like "task explorer"?
I got rid of this problem simply by restart Cygwin. The process went away after restart.
You can use the WINPID. Go into Windows Task Manager (Win 8.1), go to the "Details" tab (older versions of Windows show PID on the process tab or may require you to enable displaying it in options). You will see the PID for each process. Find the one matching the WINPID and kill it.
FYI, the PPID is the parent process. 1 means that the parent is gone (the instance of Cygwin that you closed). Depending on how the command was invoked, sometimes it'll stick around in the background even after the parent goes away. Just because the Cygwin window was closed, doesn't mean that the processes it started were stopped. I found this to be the case when piping output and one of the commands in the pipe chain locked up.
I have a script started in a screen session, then detached, tried to reattach but now this session is dead.
The script is still running.
How I can kill the script, being unable to reattach the screen session?
Unfortunatly I have killed the screen process shown with ps.
Is there any possibility to stop the script?
I assume you are in a linux enviroment, as you say you used ps. If you have the uuid of the process, you can kill it by using kill < uuid> -9. If you know the process by name, try pkill < name>. Both cases should work on a terminal. If you are unable to open a terminal, try ctrl+alt+f1. You should see a login prompt, followed by a terminal. To get back to the xsession do ctrl+alt+f7
If everything else fails, try killing all processes: kill -9 -1. This should get you back to your display manager.
If you killed your screen process, try xinit from a terminal and then try to go back.
If you can't see the process, try ps aux