How to execute a command in screen and detach?
How can I get screen to execute a command and then detach (That is, automatically in a single script without further input beyond initially starting the script)? e.g. I run myscript.sh and it automatically starts a screen session, executes a command, then detaches.
It is important to note that for many of these answers, screen will automatically terminate your screen when the command is done running and the program exits. So, you might think it didn’t work, but you are likely just not seeing it because it terminated. That is why there is a sleep or exec command in answers below, to force screen to not terminate.
8 Answers 8
-d -m
Start screen in detached mode. This creates a new session but doesn’t attach to it. This is useful for system startup scripts.
Somehow your command wasn’t found, or isn’t working correctly in the automatically-created screen environment. Try just doing screen yourcommand without the -d and -m and see how that goes first.
You’re sort of right. screen terminates when the command finishes, contrary to my expectations. But your answer does work.
You can change that by enabling the zombie option in screen. Put zombie xy in your ~/.screenrc . It should also be possible to enable it for one session only b putting zombie xy in another file and using -c file but for some reason that’s not working when I try it. Or just use sh -c ‘yourcommand;while :;do sleep 9999; done’
@AlanCurry, Nope, this doesn’t work for me either, even though the command runs perfectly (and takes several hours) when run in a screen manually.
To run a single command in screen and detach, you may try:
To run multiple commands, try:
screen -dm bash -c "sleep 10; myscript.sh" Please note that when a program terminates, screen (per default) kills the window that contained it.
If you don’t want your session to get killed after script is finished, add exec sh at the end, e.g.:
screen -dm bash -c 'sleep 5; exec sh' To list all your sessions, try:
This worked for me on Ubuntu 16.04. In addition to name your session so you can return to it later, add -S sessionname : screen -dmS MyLongRunningScript bash -c «. » .
@kenorb, the problem is that it only worked with single quotes. Let’s say: ‘for k in `seq $i $j`; do echo $k; done’ , where $i and $j are from the parent script.
This is a robust answer. I needed bash -c . I can only assume that when I called screen -dm head foo > bar it wrote screen -dm head foo to bar . screen -dm bash -c «head foo > bar» fixed that.
In order to start new session in background with name ‘sleepy’
screen -S sleepy -dm sleep 60 In order to kill ‘sleepy’ session
@Toolkit The issue is that you have the command in quotes and so it was treated as one large command. Obviously we can’t take it out of quotes because of the semicolon. To solve this, execute the command like so: screen -S sleepy -dm bash -c «cd myfolder;sleep 60»
screen -dmS screen_session_name bash -c 'echo "doing stuff"; exec bash' it happen to me when I pressed control c (sig int) to exit my program. it exits all the way from all bash. so I found this to catch SIGINT. and prevent exit from last bash. (need to type exit to exit)
screen -dmS "screenNameHere" bash -c "trap 'echo gotsigint' INT; cd /mydir ; my_command_here; bash" example: screen -dmS "status_updates" bash -c "trap 'echo gotsigint' INT; cd /opt/status_update ; forever index.js ; bash" I find it useful to use cron to run nodejs programs on startup. and to run the screen at boot time. in cron there are special events syntax @reboot event
to edit cron, execute: crontab -e then type @reboot screen -dmS "screenNameHere" bash -c "trap 'echo gotsigint' INT; cd /mydir ; my_command_here; bash" How to detach a process from terminal in unix?
When I start a process in background in a terminal and some how if terminal gets closed then we can not interact that process any more. I am not sure but I think process also get killed. Can any one please tell me how can I detach that process from my terminal. So even if I close terminal then I can interact with same process in new terminal ? I am new to unix so your extra information will help me.
Why don’t you try yourself first? Start a process in the background, log out and in again and check with ps whether the process is still around`
This strikes me as an interesting and useful question, following. I suspect processes started via the terminal will be killed when the terminal is killed. Honestly, this sounds like a fork to me, I don’t know though, I’ve never had the need to invoke a fork.
The process is killed if you logout or otherwise loose your session, unless you use the nohup command 🙂 but not sure if you can get the process back in a new session
4 Answers 4
The command you’re looking for is disown.
This is as close as you can get to a nohup. It detaches the process from the current login and allows it to continue running. Thanks David Korn!
and I just found reptyr which lets you reparent a disowned process. https://github.com/nelhage/reptyr
It’s already in the packages for ubuntu.
BUT if you haven’t started the process yet and you’re planning on doing this in the future then the way to go is screen and tmux. I prefer screen.
You might also consider the screen command. It has the «restore my session» functionality. Admittedly I have never used it, and forgot about it.
Starting the process as a daemon, or with nohup might not do everything you want, in terms of re-capturing stdout/stdin.
There’s a bunch of examples on the web. On google try, «unix screen command» and «unix screen tutorial»:
First google result for «UNIX demonizing a process»:
See the daemon(3) manpage for a short overview. The main thing of daemonizing is going into the background without quiting or holding anything up. A list of things a process can do to achieve this:
- fork()
- setsid()
- close/redirect stdin/stdout/stderr to /dev/null, and/or ignore SIGHUP/SIGPIPE.
- chdir() to /.
If started as a root process, you also want to do the things you need to be root for first, and then drop privileges. That is, change effective user to the «daemon» user or «nobody» with setuid()/setgid(). If you can’t drop all privileges and need root access sometimes, use seteuid() to temporary drop it when not needed.
If you’re forking a daemon then also setup child handlers and, if calling exec, set the close on exec flags on all file descriptors your children won’t need.
More or less what I figured. If/when I need to write a daemon, I’m sure I will have to google/stackoverflow all this nonsense myself.
‘Interact with’ can mean a couple of things.
The reason why a program, started at the command-line, exits when the terminal ends, is because the shell, when it exits, sends that process a HUP signal (see documentation for kill(1) for some introduction; HUP, by the way, is short for ‘hang up’, and originally indicated that the user had hung up the modem/telephone). The default response to a HUP signal is that a process is terminated – that is, the invoked program exits.
The details are slightly more fiddly, but this is the general intuition.
The nohup command tells the shell to start the program, and to do so in a way that this HUP signal is ignored. That is, the program keeps going after the invoking terminal exits.
You can still interact with this program by sending it signals (see kill(1) again), but this is a very limited sort of interaction, and depends on your program being written to do sensible things when it receives those signals (signals USR1 and USR2 are useful things to trap, if you’re into that sort of thing). Alternatively, you can interact via named pipes, or semaphores, or other bits of inter-process communication (IPC). That gets fiddly pretty quickly.
I suspect what you’re after, though, is being able to reattach a terminal to the process. That’s a rather more complicated process, and applications like screen do suitably complicated things behind the scenes to make that happen.
The nohup thing is a sort of quick-and-dirty daemonisation. The daemon(3) function does the daemonisation ‘properly’, doing various bits of tidy-up as described in YePhIcK’s answer, to comprehensively break the link with the process/terminal that invoked it. You can interact with that daemonised process with the same IPC tools as above, but not straightforwardly with a terminal.