I have this command in my shell script that runs forever- it wouldn't finish unless I do ctrl-c. I have been trying to look up how to send ctrl-c signal to script and all the answers have been some sort of kill $! or kill$$ or such. My problem is that the command never finishes, so it never goes on to the next command like my "kill" commands or anything else. I have to manually hit the ctrl-C in my terminal for it to even execute kill $!. I'm sure there is a way to work around this but I am not sure what. Thanks in advance!
There are several approaches to this problem. The simplest (but not most robust) is (perhaps) to simply run your long running command in the background:
#!/bin/sh
long-running-command & # run in the background
sleep 5 # sleep for a bit
kill %1 # send SIGTERM to the command if it's still running
Related
I am making the "quit" command in a script that will act like "exit" but will close down the running bash terminal.
The only way I know how to do quit is:
exit
but that does no good - it just takes it as an exit for the script, not the bash terminal session.
You can try and kill the bash process by finding the process ID using top command and then kill #ID. This can end the bash session and keep the script running.
you can try executing that command like you were a shell proccess:
execp("exit",NULL,NULL);
Sounds like you are trying to detach a script from the shell you're in. If you want to detach from the shell from within the script itself you can effectively fork it ie.
#!bin/bash
forked_function() {
# This will now be in it's worn process. Check it using
# ps ax | grep forked_function
sleep 1000;
}
forked_function &
A very common approach is to use screen. This enables you to close the terminal and come back to the running process later where you left off. If all you want to do is run a script then exit try using an ampersand appended to the script you are trying to run ie
script &
exit
That will leave chrome running but allow you to detach it it it won't close when you close the terminal. You can also manage the tasks in the background. Have a look at man jobs
script &
jobs
You can use commands like fg 1 to bring job number 1 back to the foreground etc.
I am running a shell script, something like sh script.sh in bash. The script contains many lines, some of which take seconds and others take days to execute. How can I kill the sh command but not kill its command currently running (the current line from the script)?
You haven't specified exactly what should happen when you 'kill' your script., but I'm assuming that you'd like the currently executing line to complete and then exit before doing any more work.
This is probably best achieved only by coding your script to behave in such a way as to receive such a kill command and respond in an appropriate way - I don't think that there is any magic to do this in linux.
for example:
You could trap a signal and then set a variable
Check for existence of a file (e.g touch /var/tmp/trigger)
Then after each line in your script, you'd need to check to see if each the trap had been called (or your trigger file created) - and then exit. If the trigger has not been set, then you continue on and do the next piece of work.
To the best of my knowledge, you can't trap a SIGKILL (-9) - if someone sends that to your process, then it will die.
HTH, Ace
The only way I can think of achieving this is for the parent process to trap the kill signal, set a flag, and then repeatedly check for this flag before executing another command in your script.
However the subprocesses need to also be immune to the kill signal. However bash seems to behave different to ksh in this manner and the below seems to work fine.
#!/bin/bash
QUIT=0
trap "QUIT=1;echo 'term'" TERM
function terminated {
if ((QUIT==1))
then
echo "Terminated"
exit
fi
}
function subprocess {
typeset -i N
while ((N++<3))
do
echo $N
sleep 1
done
}
while true
do
subprocess
terminated
sleep 3
done
I assume you have your script running for days and then you don't just want to kill it without knowing if one of its children finished.
Find the pid of your process, using ps.
Then
child=$(pgrep -P $pid)
while kill -s 0 $child
do
sleep 1
done
kill $pid
Let me explain better. What is gonna happen if I run a command in Linux and before it's done and you could enter another command I close the terminal. Would it still do the command or not?
Generally, you must expect that closing your terminal will hangup your command. But fear not! Linux has a solution for that too!
To ensure that your command completes, use the nohup argument first. Simply place it before whatever you are trying to do:
nohup ./some_program
nohup ./do_a_thing -frx -file input_file.txt
nohup grep "something" giant_list_of_files/* > temp_file.txt
The nohup command stands for "no hangup" and it will ensure that the command you execute continues to run, even if you close your terminal.
It depends on the process and your environment (job control shell options, VNC, etc). But typically, no. The process will get a "hangup" signal (message) from the operating system, and upon receiving that, will quit.
The nohup command, for example, arranges for processes to ignore the hangup signal from the OS. There are many ways to achieve the same result.
I would say it will abort att the status you are in just before the session close.
If you want to be sure to complete the job, you will need to use the nohup command.
http://en.wikipedia.org/wiki/Nohup
Read about nohups and daemons (-d)...
A good link is [link]What's the difference between nohup and a daemon?
Worth look at screen command, Screen command offers the ability to detach a long running process (or program, or shell-script) from a session and then attach it back at a later time.
how can I continously run a script in background without using crontab. The script should run even after I logout and is acceptable if it doesen't start after system reboot.I am new to unix.
There's a couple of ways of doing this but the neatest way is to use screen. This lets you create a session which lives perminently on the machine and you can simply reconnect to to check on the progress of your long running process.
If you don't wish to use screen you can use nohup this allows you to run a task like:
nohup mytask &
Your task will now run in the background and will survive a log off, however there's no way to take control of it again, unlike with screen.
if [ "x$1" != "x--" ]; then
$0 -- 1> /dev/null 2> /dev/null &
exit 0
fi
This is how you can run a script as a daemon. First your script (the father) will create a copy of himself (a child) so it is considerd as a process of the father. Then the father kills itself while the child is still running. Guess what happens when you do such a thing ? The child is attached to the init process. So even if you logout, the script will still run.
You can even start it without the "&" operator because you start the father which is killed a millisecond after.
You can take control over it again like any program running on your computer.
By the way it's not a real "daemon" program, it's just kind of emulation. You can't just start it at the boot (I mean really the BOOT and not the loggin) if you want to start it as you login, quite simple put it in your .xinitrc
The main advantage of this solution is that your script doesn't depend on any other programm such as "nohup" which is really bad I think.
Regards
PS : If you want some informations about what the command above does, just ask me. It's just a "parameter" thing.
As others have mentioned before, you need to use nohup to prevent the process from getting the hangup signal (hence no-h-up).
However, if you start the process in the background to begin with, as
prompt> nohup process &
that has the disadvantage of not allowing you to enter any data that may be required to get the process started off. This may be passwords/credentials or other input the process needs.
If you have that requirement, start it without the "&" at the end, enter your input and then hit Ctrl-Z to put the process to sleep. To send it to the background, type "bg" at the prompt and hit Enter.
prompt> nohup process
Enter password:
(Now press Ctrl-Z)
[1]+ Stopped process
prompt> bg
[1]+ process &
Now even if you log off, the process will continue to run in the background.
Alternatively if you are using bash or zsh, if you didn't start the process with nohup to begin with, and killing it and restarting is not an option then you can use the built-in disown command. First pause and background the process. And then stop hangup signals from reaching it.
prompt> process
Enter password:
(Now press Ctrl-Z)
[1]+ Stopped process
prompt> bg
[1]+ process &
prompt> disown -h
Note: If you've got other background jobs running, you need to provide the jobspec to only disown this specific job.
prompt> disown -h %1
Instead of [1] if you'd seen [2] when you paused and sent the process to the background, you'd say disown -h %2 instead.
As well as starting it in the background, as above, you may need to use 'nohup'. This means it will carry on running, even if you close the terminal.
nohup ./abc.sh &
start it in background using & operator e.g.
./abc.sh & this will continue till (a) the execution is complete or (b) you kill it or (c) system reboots
I'm trying to use a shell script to start a command. I don't care if/when/how/why it finishes. I want the process to start and run, but I want to be able to get back to my shell immediately...
You can just run the script in the background:
$ myscript &
Note that this is different from putting the & inside your script, which probably won't do what you want.
Everyone just forgot disown. So here is a summary:
& puts the job in the background.
Makes it block on attempting to read input, and
Makes the shell not wait for its completion.
disown removes the process from the shell's job control, but it still leaves it connected to the terminal.
One of the results is that the shell won't send it a SIGHUP(If the shell receives a SIGHUP, it also sends a SIGHUP to the process, which normally causes the process to terminate).
And obviously, it can only be applied to background jobs(because you cannot enter it when a foreground job is running).
nohup disconnects the process from the terminal, redirects its output to nohup.out and shields it from SIGHUP.
The process won't receive any sent SIGHUP.
Its completely independent from job control and could in principle be used also for foreground jobs(although that's not very useful).
Usually used with &(as a background job).
nohup cmd
doesn't hangup when you close the terminal. output by default goes to nohup.out
You can combine this with backgrounding,
nohup cmd &
and get rid of the output,
nohup cmd > /dev/null 2>&1 &
you can also disown a command. type cmd, Ctrl-Z, bg, disown
Alternatively, after you got the program running, you can hit Ctrl-Z which stops your program and then type
bg
which puts your last stopped program in the background. (Useful if your started something without '&' and still want it in the backgroung without restarting it)
screen -m -d $command$ starts the command in a detached session. You can use screen -r to attach to the started session. It is a wonderful tool, extremely useful also for remote sessions. Read more at man screen.