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.
Related
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 8 months ago.
Improve this question
I start my script bash test.sh and then press Control-Z and get this:
^Z
[1]+ Stopped bash test.sh
All fine. But I want that the output also has the PID.
I know I can do this ps $(jobs -p) afterwards to get the PID. But how it is possible that the output of Control-Z prints directly the PID?
I don't think that's possible. That said, perhaps you can take a step back and clarify why you are hoping to do that?
Because what you can do is directly refer to the particular job with %1 (or %<n> more generally, if you have multiple background jobs) for several built-in commands (fg, bg, kill, ...):
$ sleep 30
^Z
[1]+ Stopped sleep 30
$ kill %1
[1]+ Terminated: 15 sleep 30
More details in man bash or here: https://www.gnu.org/software/bash/manual/bash.html#Job-Control-Basics
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.
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 3 years ago.
Improve this question
I have a a.sh script that executes a infinite loop with a list of commands in background in a Debian machine and I would like to use another script b.sh to end with a.sh. As far as I know pkill -f a.sh is one way of doing it, but I want to know if there is another way of doing it
man -k kill shows many commands to kill processes. Watch out (1) (general commands) and (8) (admin commands). At my system I get (manually filtered):
killproc (8) - Send signals to processes by full path name
docker-container-kill (1) - Kill one or more running containers
docker-kill (1) - Kill one or more running containers
kill (1) - terminate a process
killall (1) - kill processes by name
killall5 (8) - send a signal to all processes.
pkill (1) - look up or signal processes based on name and other attributes
skill (1) - send a signal or report process status
If you run a.sh from b.sh you can get the process id of a.sh
b.sh
a.sh & # Execute a.sh in the background
APID=$! # $APID is now the pid of a.sh
#do some stuff or wait
kill -SIGTERM $APID # Give the process a chance to shut down
kill -SIGKILL $APID # Certain kill
This way you can kill the particular instance of a.sh if you have multiple concurrent
instances.
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.