Two emacs server are running on my machine
$ ps -ef |grep emacs | sed "s/$USER/me/g"
me 4010 1 6 13:52 ? 00:02:58 /snap/emacs/25/usr/bin/emacs --daemon=orging
me 4538 1 3 13:52 ? 00:01:45 /snap/emacs/25/usr/bin/emacs --daemon=coding
me 4622 1 0 13:52 pts/1 00:00:00 /snap/emacs/25/usr/bin/emacsclient /home/me/ORG/os.org -c -s orging
me 4623 1 0 13:52 pts/1 00:00:00 /snap/emacs/25/usr/bin/emacsclient /home/me/ORG/algorithms.org -c -s coding
me 8945 3548 0 14:38 pts/1 00:00:00 grep --color=auto emacs
The one of 'orging` is frozen,
Upon reading debugging - What do I do when Emacs is frozen? - Emacs Stack Exchange, I got the solution
pkill -SIGUSR2 emacs
How could apply the operation to the specified emacs saying 'orging'?
Use the kill command and specify the pid of the emacs instance you want, in this case 4010:
kill -SIGUSR2 4010
Related
I am trying to understand this script:
#!/usr/bin/env sh
trap "pkill -f sleep" term
sleep 1000
After running the script, I would like to stop it by sending a SIGTERM:
# run script in the background
$ ./signals.sh &
[1] 5389
# check if script is running
$ ps aux | grep 'signals.sh\|sleep' | grep -v grep
sergioro 5389 0.0 0.0 216520 3112 pts/0 S 09:07 0:00 sh ./signals.sh
sergioro 5390 0.0 0.0 214984 708 pts/0 S 09:07 0:00 sleep 1000
# send SIGTERM to script
$ pkill -fe signals.sh
sh killed (pid 5389)
# why hasn't the script stopped after receiving SIGTERM?
$ ps aux | grep 'signals.sh\|sleep' | grep -v grep
sergioro 5389 0.0 0.0 216520 3112 pts/0 S 09:07 0:00 sh ./signals.sh
sergioro 5390 0.0 0.0 214984 708 pts/0 S 09:07 0:00 sleep 1000
# send SIGTERM to `sleep` command
$ pkill -fe sleep
sleep killed (pid 5390)
Terminated
# script has stopped
$ ps aux | grep 'signals.sh\|sleep' | grep -v grep
My question is how to stop the script by sending SIGTERM to the script itself and not to the sleep command? And why is the trap in the script not terminating the sleep command?
The shell can process trap only after sleep finishes.
This can achieve what you expected :
#!/usr/bin/env sh
trap "pkill -f sleep" term
sleep 1000 & wait
See the SIGNALS section of the man page, especially the last paragraph:
If bash is waiting for a command to complete and receives a signal for
which a trap has been set, the trap will not be executed until the command completes. When bash is waiting for an asynchronous command via
the wait builtin, the reception of a signal for which a trap has been
set will cause the wait builtin to return immediately with an exit status greater than 128, immediately after which the trap is executed.
My question revolves around a process I'm using to update a status file. I have a process running which does a simple
sed -i "s/info/newinfo/" file.txt
But this process can be called multiple times.
My question is, if two processes are running a sed command to modify the file at the same time, would that cause a problem?
I tried to test this by running 2 at commands at the same time doing two different sed modifications. They seem to work fine but I don't know if they were actually simultaneously or not. Maybe the command is so fast that it won't have a problem with read and write access from two different processes.
Ok let show, with a not so big file:
cd /tmp
seq 1000000 2000000 > mediumfile.txt
ls -hl mediumfile.txt
-rw-r--r-- 1 user user 7.7M Sep 26 16:53 host file.txt
wc mediumfile.txt
1000001 1000001 8000008 host file.txt
Ok, there is 1000k lines in my 7.7Mb file.
If I drop 2 x 1001 lines simultaneously by two separated (stream) process (from 1801000 to 1802000 and from 1803000 to 1804000).
sed '/1803000/,/1804000/d' -i mediumfile.txt & \
sed '/1801000/,/1802000/d' -i mediumfile.txt ;wait
[1] 30727
[1]+ Done sed '/1803000/,/1804000/d' -i mediumfile.txt
wc -l mediumfile.txt
999000 host file.txt
There are 1k line too much!
grep '180[13]400' mediumfile.txt
1803400
So it is.
Try as I might I cannot kill these celery workers.
I run:
celery --app=my_app._celery:app status
I see I have 3 (I don't understand why 3 workers = 2 nodes, please explain if you know)
celery#ip-x-x-x-x: OK
celery#ip-x-x-x-x: OK
celery#named-worker.%ip-x-x-x-x: OK
2 nodes online.
I run (as root):
ps auxww | grep 'celery#ip-x-x-x-x' | awk '{print $2}' | xargs kill -9
The workers just keep reappearing with a new PID.
Please help me kill them.
A process whose pid keeps changing is called comet. Even though pid of this process keeps on changing, its process group ID remains constant. So you can kill by sending a signal.
ps axjf | grep '[c]elery' | awk '{print $3}' | xargs kill -9
Alternatively, you can also kill with pkill
pkill -f celery
This kills all processes with fullname celery.
Reference: killing a process
pkill -f celery
Run from the command line, this will kill at processes related to celery.
In your console, type :
ps -aux | grep celery
I get :
simon 24615 3.8 0.6 344276 219604 pts/3 S+ 22:53 0:56 /usr/bin/python3 /home/simon/.local/bin/celery -A worker_us_task worker -l info -Q us_queue --concurrency=30 -n us_worker#%h
select what you find after -A and type :
pkill -9 -f 'worker_us_task worker'
I always use:
ps auxww | grep 'celery' | awk '{print $2}' | xargs kill -9
If you're using supervisord to run celery, you need to kill supervisord process also.
I found a problem, can anyone help to solve?
My Ubuntu "top" command cannot display Chinese characters correctly. It's using unrecognized characters, see the below:
joe#joe-us:~/app$ top -bc -n 1|grep home
1989 joe 20 0 34760 2564 2148 S 0 0.1 0:00.00 /usr/lib/gvfs//gvfs-fuse-daemon -f /home/joe/.gvfs
9577 joe 20 0 217m 40m 19m S 0 1.0 3:01.42 /home/joe/��?�?�/�?� sublime_text �??�?��?�
13885 joe 20 0 5828 820 732 S 0 0.0 0:00.00 grep --color=auto home
joe#joe-us:~/app$
For the same process, command "ps" works OK.
joe#joe-us:~/app$ ps -ef|grep home
joe 1989 1 0 10:11 ? 00:00:00 /usr/lib/gvfs//gvfs-fuse-daemon -f /home/joe/.gvfs
joe 9577 1 1 12:00 ? 00:03:01 /home/joe/桌面/到 sublime_text 的链接
joe 13883 12362 0 16:36 pts/0 00:00:00 grep --color=auto home
My system can support Chinese characters well now, here is the environment
joe#joe-us:~/app$ echo $LANGUAGE
zh_CN:zh
joe#joe-us:~/app$
joe#joe-us:~/桌面$ ls
aliedit.sh github github~ keeper.php Logo root root~ 到 sublime_text 的链接
joe#joe-us:~/桌面$
joe#joe-us:~$ echo $TERM
xterm
right display:/home/joe/桌面/到 sublime_text 的链接
wrong display:/home/joe/��?�?�/�?� sublime_text �??�?��?�
Thank you very much!
Pervious answers to this questions have focused on forks:
kill background process when shell script exit
How to make child process die after parent exits?
Are child processes created with fork() automatically killed when the parent is killed?
For this question, I'm just asking about calls to the 'system' function.
Say I have a script called sleep.pl:
use strict;
use warnings;
sleep(300);
I then have a script called kill.pl
use strict;
use warnings;
system("sleep.pl");
I run kill.pl and using ps I find the process id of kill.pl and kill it (not using kill -9, just normal kill)
sleep.pl is still sleeping.
I imagine the solution to my question involves a SIG handler, but what do I need to put into the handler to kill the child process?
Use setsid to make your process the new group leader. Then you can send a kill to the group ID and kill all processes that belong to the group. All processes that you spawn from the leader process inherit the group ID and belong to your newly created group. So sending a kill to the group will kill them all. The only tricky thing is in order to be able to use setsid you must close your standard in and output, as that is a requirement for setsid.
use strict;
use warnings;
setpgrp $$, 0;
system("sleep.pl");
END {kill 15, -$$}
But if you need this approach you do something wrong. You should not do this. Run and kill your kill process in right way instead.
$ perl -e 'system("sleep 100")' &
[1] 11928
$ ps f
PID TTY STAT TIME COMMAND
4564 pts/1 Ss 0:01 /bin/bash
11928 pts/1 S 0:00 \_ perl -e system("sleep 100")
11929 pts/1 S 0:00 | \_ sleep 100
11936 pts/1 R+ 0:00 \_ ps f
$ kill %1
[1]+ Terminated perl -e 'system("sleep 100")'
$ ps f
PID TTY STAT TIME COMMAND
4564 pts/1 Rs 0:01 /bin/bash
11949 pts/1 R+ 0:00 \_ ps f
How it works? Shell (bash in mine case) should set your process as group leader if you run on background. Then if you use kill %? syntax shell kills group in right way. Compare this:
$ perl -e 'system("sleep 100")' &
[1] 12109
$ ps f
PID TTY STAT TIME COMMAND
4564 pts/1 Rs 0:01 /bin/bash
12109 pts/1 S 0:00 \_ perl -e system("sleep 100")
12113 pts/1 S 0:00 | \_ sleep 100
12114 pts/1 R+ 0:00 \_ ps f
$ kill 12109
[1]+ Terminated perl -e 'system("sleep 100")'
$ ps f
PID TTY STAT TIME COMMAND
4564 pts/1 Ss 0:01 /bin/bash
12124 pts/1 R+ 0:00 \_ ps f
12113 pts/1 S 0:00 sleep 100
But kill %? works in this way:
$ perl -e 'system("sleep 100")' &
[1] 12126
$ ps f
PID TTY STAT TIME COMMAND
4564 pts/1 Rs 0:01 /bin/bash
12126 pts/1 S 0:00 \_ perl -e system("sleep 100")
12127 pts/1 S 0:00 | \_ sleep 100
12128 pts/1 R+ 0:00 \_ ps f
$ kill -12126
[1]+ Terminated perl -e 'system("sleep 100")'
$ ps f
PID TTY STAT TIME COMMAND
4564 pts/1 Ss 0:01 /bin/bash
12130 pts/1 R+ 0:00 \_ ps f
Your question really is a specific instance of the more general "how to ensure a child dies when the parent dies" question. There's just no getting around that. There's nothing really special about system(); it just forks a child process and waits for it to exit.
system() is roughly this:
sub system
{
my $kidpid = fork;
if ( $kidpid )
{
waitpid $kidpid;
# parent process blocks here waiting for the child process to return
}
else
{
exec( #_ );
}
}
Killing the process group is about your only option.