Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed 2 years ago.
Improve this question
This might be a very basic question but I couldn't find it anywhere on the internet.
Lets assume I have a file named test with this code
echo hello
sleep 10
echo hello
sleep 10
echo hello
sleep 10
How would I go about killing that program through another terminal in my server?
I am assuming the file is test.sh
You can do:
ps -x | grep ./test.sh
This will show the processes:
11164 pts/1 S+ 0:00 /usr/bin/bash ./test.sh
and a second process that will be a grep process, you won't be able to kill the process that has the word grep in it because that process completes right away
now you can kill the process using the PID:
kill 11164
Your script filename is test.
So, in another terminal, you can execute ps aux | grep test.
Then you can get the PID of test, which is located at the second column.
Then, execute kill -9 <PID>.
Ctrl c
By Pressing this, you can kill that program from your terminal.
And you can kill this program from your main terminal where you exicute this in first place.
Related
Let's say I have a silly script:
while true;do
touch ~/test_file
sleep 3
done
And I start the script into the background and leave the terminal:
chmod u+x silly_script.sh
./silly_script.sh &
exit
Is there a way for me to identify and stop that script now? The way I see it is, that every command is started in it's own process and I might be able to catch and kill one command like the 'sleep 3' but not the execution of the entire script, am I mistaken? I expected a process to appear with the scripts name, but it does not. If I start the script with 'source silly_script.sh' I can't find a process by the name of 'source'. Do I need to identify the instance of bash, that is executing the script? How would I do that?
EDIT: There have been a few creative solutions, but so far they require the PID of the script execution to be stored right away, or the bash session to not be left with ^D or exit. I understand, that this way of running scripts should maybe be avoided, but I find it hard to believe, that any low privilege user could, even by accident, start an annoying script into the background, that is for instance filling the drive with garbage files or repeatedly starting new instances of some software and even the admin has no other option, than to restart the server, because a simple script can hide it's identifier without even trying.
With the help of the fine people here I was able to derive the answer I needed:
It is true, that the script runs every command in it's own process, so for instance killing the sleep 3 command won't do anything to the script being run, but through a command like the sleep 3 you can find the bash instance running the script, by looking for the parent process:
So after doing the above, you can run ps axf to show all processes in a tree form. You will then find this section:
18660 ? S 0:00 /bin/bash
18696 ? S 0:00 \_ sleep 3
Now you have found the bash instance, that is running the script and can stop it: kill 18660
(Of course your PID will be different from mine)
The jobs command will show you all running background jobs.
You can kill background jobs by id using kill, e.g.:
$ sleep 9999 &
[1] 58730
$ jobs
[1]+ Running sleep 9999 &
$ kill %1
[1]+ Terminated sleep 9999
$ jobs
$
58730 is the PID of the backgrounded task, and 1 is the task id of it. In this case kill 58730 and kill %1` would have the same effect.
See the JOB CONTROL section of man bash for more info.
When you exit, the backgrounded job will get a kill signal and die (assuming that's how it handles the signal - in your simple example it is), unless you disown it first.
That kill will propogate to the sleep process, which may well ignore it and continue sleeping. If this is the case you'll still see it in ps -e output, but with a parent pid of 1 indicating its original parent no longer exists.
You can use ps -o ppid= <pid> to find the parent of a process, or pstree -ap to visualise the job hierarchy and find the parent visually.
Closed. This question is not reproducible or was caused by typos. It is not currently accepting answers.
This question was caused by a typo or a problem that can no longer be reproduced. While similar questions may be on-topic here, this one was resolved in a way less likely to help future readers.
Closed 2 years ago.
Improve this question
I am having trouble with exiting past nodemon instance.
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
node 98355 user 14u IPv6 0x51b8b9857a4e56a3 0t0 TCP *:redwood-broker (LISTEN)
It has taken my 3000 port so I am trying to exit it. I searched it by using lsof -wni tcp:3000
I could see that PID is 98335, so tried kill 98335, kill -9 98335, sudo kill 98335, sudo kill -9 98335 and so on but no luck, it's just saying
kill: kill 98335 failed: no such process
But if I save something, nodemon watching job is printing out to console, which means that process is still alive.
Please help me.
https://github.com/remy/nodemon/issues/1386
To work around the issue, find the proces running on the port number and kill it:
kill -9 $(lsof -t -i:3000)
OR
Install 1.17.5 npm install nodemon#1.17.5 --save-dev --save-exact.
you can use
ps -ef | grep node
to find the process id
and then
sudo kill -9 <PID>
PID is the process ID. Try the following command in terminal to list and search for process using a regex:-
ps gx | grep 'Symantec'
The above example is to list all the 'Symantec' related processes. Replace 'Symantec' with your own phrase. Next use variations of 'kill' command. You can either use:-
kill pid
Replace 'pid' with actual process id. Or use,
killall
as suggested before. To reiterate another useful suggestion, use
man kill
to see the manual for 'kill' command and also scroll down and see related commands which is mentioned under.
to kill all running node processes with -9 option
sudo pkill -f node -9
sudo kill -9 PID
This will forcefully kill your process
you kill wrong PID its 98355 not 98335
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 7 years ago.
Improve this question
I am pretty new to Unix system commands and architecture. I find a few concepts pretty confusing and have been left with some unanswered questions, like: how many shells can be spawned in a single user's login session? does the number of shells have at all anything to do with a user's login?
While exploring system commands, I tried the following:
Opened a terminal window, say Terminal 1. Typed the following commands in order:
sleep 300
^z(ctrl+z)
bg
jobs
ps
Output for jobs:
[1]+ Running sleep 300 &
Output for ps:
PID TTY TIME CMD
3301 pts/1 00:00:00 bash
4494 pts/1 00:00:00 sleep
4497 pts/1 00:00:00 ps
Without wasting any further time (300 seconds were far from being spent), I opened another terminal, lets name it Terminal 2. I entered the following commands in order:
jobs
ps
Output for jobs: -no output, command prompt returned-
Output for ps:
PID TTY TIME CMD
4478 pts/3 00:00:00 bash
4496 pts/3 00:00:00 ps
I am wondering why the backgrounded sleep job (with Process ID 4494), executed in Terminal 1 wasnt listed in Terminal 2, neither with jobs, nor ps.
Can somebody please explain to me what exactly happened here?
The shell in terminal 1 is bash with a PID of 3301. The shell in terminal 2 is bash with a PID of 4478. So yes, each terminal window is running an independent copy of the shell.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 9 years ago.
Improve this question
I've run a multithreading program in background:
./my_task &
Then I logged out, then logged again. Now jobs command does not show this program, but top does show the threads of this program. So it is still running. How to stop it? I guess I can kill each thread, but there are many of them and I don't know how it will affect my_task program.
I am using Debian Squeeze.
In common case, you can use
ps aux | grep my_task
-or, if you know, that process name starts with "my_task" exactly:
ps aux | grep [m]y_task
(this will exclude grep process itself from result table)
to get desired process id (let it be $pid) and then kill it with kill $pid
edit (thanks to comments below): jobs is part of bash itself, and so information about it is listed in man bash page:
Job control refers to the ability to selectively stop (suspend) the
execution of processes and continue
(resume) their execution at a later point. A user typically employs this facility via an interactive
interface supplied jointly by the operating system kernel's terminal driver and bash.
The shell associates a job with each pipeline. It keeps a table of currently executing jobs, which may
be listed with the jobs command. When bash starts a job asynchronously (in the background), it prints a
line that looks like:
[1] 25647
indicating that this job is job number 1 and that the process ID of the last process in the pipeline
associated with this job is 25647. All of the processes in a single pipeline are members of the same
job. Bash uses the job abstraction as the basis for job control.
but this will not help a case since it will list jobs only for current instance (which, of cause, will change when you're changing your session)
run your proces with log. I have used gnome-calculator for example:
gnome-calculator & echo $! > tmp/11/mylog
and add below to .bashrc or other autostart for kill it:
kill `cat tmp/11/mylog`
You can use pgrep to find the command:
$ pgrep my_task
4384
Then you can use that output to make sure it's the command you want:
$ ps -fp 4384 | cat
I pipe the output to cat because the ps command will chop off the output at the rowsize of the terminal unless it's piped to another command.
You could combine them too:
$ ps -fp $(pgrep my_task) | cat
You can also use pkill if you're brave:
$ pkill my_task
This will kill any processes that match the regular expression my_task that is owned by the user.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
I thought I could just use this related question: How Do I write a bash script to restart a process if it dies. #lhunath had a great answer and told me everything I might do about it was wrong, but I'm restarting a daemon process and if I'm hoping there's something I can do in a single script that works.
my process starts with a kick off script that shows the startup log, but then quits and leaves the process running off the shell:
>sudo ./start
R CMD Rserve --RS-conf /var/FastRWeb/code/rserve.conf --vanilla --no-save
...
Loading required package: FastRWeb
FastRWeb: TRUE
Loading data...
Rserv started in daemon mode.
>
The process is up and running,
ps -ale | grep Rserve
1 S 33 16534 1 0 80 0 - 60022 poll_s ? 00:00:00 Rserve
Is there a simple way to wrap or call the 'start' script from bash and restart when the process dies or is this a case where PID files are actually called for?
Dang - question got closed even after pointing to a very similar question that was not closed on stackoverflow. you guys suck
A very simple way to monitor the program is to use cron: check every minute (or so) if the program still is alive, ./start it otherwise.
As root, invoke crontab -e.
Append a line like this:
* * * * * if ! pidof Rserve 2>&1 >/dev/null; then /full/path/to/start; fi
This method will stay persistent, i.e., it will be executed after a reboot etc. If this is not what you want, move it to a shell script:
#! /bin/bash
# monitor.sh
while true; do
if ! pidof Rserve 2>&1 >/dev/null; then /full/path/to/start; fi
sleep 10
done
This script has to be started manually from the command line, and can be easily stopped with Ctrl-C.
The easiest solution, if you can run the process is NON-daemon mode, is to wrap it in a script.
#!/bin/bash
while (true)
do
xmessage "This is your process. Click OK to kill and respawn"
done
Edit
Many deamons leave a lock file, usually in /var/lock, that contains their PID. This keeps multiple copies of the deamon from running.
Under Linux, it is fairly simple to look throgh /proc and see if that process is still around.
Under other platforms you may need to play games with ps to check for the processes existence.