Keeping a linux process running after I logout

Question

I'm connecting to a Linux machine through SSH, and I'm trying to run a heavy bash script that makes filesystem operations. It's expected to keep running for hours, but I cannot leave the SSH session open because of internet connections issues I have.

I doubt that running the script with the background operator, the ampersand (&), will do the trick, because I tried it and later found that process was not completed. How can I logout and keep the process running?

score 138 · Accepted Answer · edited Apr 13 '17 at 12:37

138

The best method is to start the process in a terminal multiplexer. Alternatively you can make the process not receive the HUP signal.

A terminal multiplexer provides "virtual" terminals which run independent from the "real" terminal (actually all terminals today are "virtual" but that is another topic for another day). The virtual terminal will keep running even if your real terminal is closed with your ssh session.

All processes started from the virtual terminal will keep running with that virtual terminal. When you reconnect to the server you can reconnect to the virtual terminal and everything will be as if nothing happened, other than the time which passed.

Two popular terminal multiplexers are screen and tmux.

Screen has a steep learning curve. Here is a good tutorial with diagrams explaining the concept: http://www.ibm.com/developerworks/aix/library/au-gnu_screen/

The HUP signal (or SIGHUP) is sent by the terminal to all its child processes when the terminal is closed. The common action upon receiving SIGHUP is to terminate. Thus when your ssh session gets disconnected all your processes will terminate. To avoid this you can make your processes not receive SIGHUP.

Two easy methods to do so are nohup and disown.

For more information about how nohup and disown works read this question and answer: https://unix.stackexchange.com/questions/3886/difference-between-nohup-disown-and

Note: although the processes will keep running you can no longer interact with them because they are no longer attached to any terminal. This method is mainly useful for long running batch processes which, once started, no longer need any user input.

edited Apr 13 '17 at 12:37

Community

1

answered Sep 15 '11 at 06:05

Lesmana

2,324

3

I like this answer as it provides a solution for both interactive and non-interactive situations. In the interactive case, screen gives you a lot more options, but if you are using authorized_keys to allow people to run a script remotely via ssh, the nohup option is a nice simple way for the script to start processes which last longer than the ssh session used to start them. – Mark Booth Sep 15 '11 at 10:33
lesmana, and @Mark Booth I like your answers as it tells more useful tips.. 1+ – doc_id Sep 15 '11 at 17:17
1

@rahmanisback - Remember that you can change your accepted answer at any time. Just because so far EricA's answer is voted most highly doesn't mean it's the best answer for you, indeed making it your accepted answer may well encourage more people to vote it up as a good answer. – Mark Booth Sep 15 '11 at 23:02
Well, I lost an accepted answer, but gained the gold "populist" badge. :) w00t. – EEAA Sep 15 '11 at 23:18
3

*cough*tmuxisbetter*cough* – crasic Sep 16 '11 at 00:07
@crasic please don't start :) – doc_id Sep 16 '11 at 00:13
@ErikA Yes. I noticed one thing.. An accepted answer tends to get more up votes dramatically. – doc_id Sep 16 '11 at 00:16
3

tmux > screen. Try it, you'll never go back. – h0tw1r3 Sep 16 '11 at 15:31
byobu > screen. Tried it, never turned back – TheLQ Sep 16 '11 at 19:35
1

@TheLQ - byobu is GNU Screen. You're still using screen, just with a highly-customized .screenrc. – EEAA Sep 16 '11 at 21:34
1

screen is dead. tmux is king. Old hats prefer nohup. – Cees Timmerman Jun 17 '15 at 15:02
nohup is not needed in modern shells. – chicks Jun 22 '15 at 01:57
tmux FTW ☺︎ ☺︎☺︎ – code_monk Oct 07 '16 at 22:23

score 94 · Answer 2 · answered Sep 15 '11 at 06:07

94

There are a few ways to do this, but the one I find most useful is to use GNU Screen.

After you ssh in, run screen. This will start another shell running within screen. Run your command, then do a Ctrl-a d.

This will "disconnect" you from the screen session. At this point, you can log out or do anything else you'd like.

When you want to re-connect to the screen session, just run screen -RD from the shell prompt (as the same use user that created the session).

answered Sep 15 '11 at 06:07

EEAA

109,904

6

Screen has a whole bunch of command, all starting with Ctrl-a. If you only learn one extra, start with "Ctrl-a ?". Then you'll wan't to learn "Ctrl-a c" and "Ctrl-a n" – olafure Sep 15 '11 at 12:06
1

@olafure +1, thanks. Looks like Screen is going to be of my primary toolbox. – doc_id Sep 15 '11 at 17:11
tmux > screen. Try it, you'll never go back. – h0tw1r3 Sep 16 '11 at 15:31
+1 for tmux. I gave up screen 5 weeks ago. – Bryan Hunt Jun 06 '12 at 08:46

score 78 · Answer 3 · edited Nov 26 '14 at 20:06

78

In bash, the disown keyword is perfectly suited to this. First, run your process in the background (either use &, or ^Z then type bg):

$ wget --quiet http://server/some_big_file.zip &
[1] 1156

By typing jobs you can see that the process is still owned by the shell:

$ jobs
[1]+  Running  wget

If you were to log out at this point, the background task would also get killed. However, if you run disown, bash detaches the job and allows it to continue running:

$ disown

You can confirm this:

$ jobs
$ logout

You can even combine the & and disown on the same line, like:

$ wget --quiet http://server/some_big_file.zip & disown
$ logout

This is better than running nohup in my opinion because it doesn't leave nohup.out files littered all over your filesystem. Also, nohup must be run before you run the command — disown can be used if you only decide later on that you want to background and detach the task.

edited Nov 26 '14 at 20:06

Greg

167

answered Sep 15 '11 at 12:27

Jeremy Visser

1,444
8
16

1

That's a very good answer, 1+. The only preference for nohup or Screen would be the independence of bash, and might be used with other shell. But I will stick to your approach whenever I'm using bash. – doc_id Sep 15 '11 at 17:34
Yes – this is bash–specific, as bash is the only shell I've ever used. I wonder if other shells support anything similar (i.e. launching in background without nohup) – it would be fantastic if someone could post other answers for other shells. – Jeremy Visser Sep 16 '11 at 02:46
1

see my answer showing how to do it it with any sh-lookalike – w00t Sep 16 '11 at 16:49
2

+1 because of being able to decide later. Just this moment i had a need for this. worked as advertised – code_monk Nov 02 '14 at 03:45

score 38 · Answer 4 · edited Sep 15 '11 at 13:35

38

The tool nohup, available on most Linux boxes will do this.

edited Sep 15 '11 at 13:35

Danny Staple

1,494

answered Sep 15 '11 at 06:14

Korjavin Ivan

2,270

2

This is by far the simplest answer. Any output from is automatically directed to nohup.out and can be examined later. – Julian Sep 15 '11 at 10:01
3

nohup does not require zsh at all. – Aaron Brown Sep 15 '11 at 11:55
nohup is the correct answer, it is short for no hangup. – Kinjal Dixit Sep 15 '11 at 19:18
2

nohup is found on far more machines then screen, so you should know how to use it. – Zenon Sep 15 '11 at 21:11

score 27 · Answer 5 · answered Sep 15 '11 at 06:23

Just to be thorough, I'll point out tmux, which has the same basic idea as screen:

tmux is intended to be a modern, BSD-licensed alternative to programs such as GNU screen. Major features include:

A powerful, consistent, well-documented and easily scriptable command interface.

A window may be split horizontally and vertically into panes.

Panes can be freely moved and resized, or arranged into preset layouts.

Support for UTF-8 and 256-colour terminals.

Copy and paste with multiple buffers.

Interactive menus to select windows, sessions or clients.

Change the current window by searching for text in the target.

Terminal locking, manually or after a timeout.

A clean, easily extended, BSD-licensed codebase, under active development.

It is, however, approximately infinitely easier to search for on Google.

Using "gnu screen" as your search query works quite well. – gnur Sep 15 '11 at 07:45 — gnur, Sep 15 '11 at 07:45

score 13 · Answer 6 · answered Sep 15 '11 at 15:06

Screen is overkill for just keeping processes running when you logout.

Try dtach:

dtach is a program written in C that emulates the detach feature of screen, which allows a program to be executed in an environment that is protected from the controlling terminal. For instance, the program under the control of dtach would not be affected by the terminal being disconnected for some reason.

dtach was written because screen did not adequately meet my needs; I did not need screen's extra features, such as support for multiple terminals or terminal emulation support. screen was also too big, bulky, and had source code that was difficult to understand.

screen also interfered with my use of full-screen applications such as emacs and ircII, due to its excessive interpretation of the stream between the program and the attached terminals. dtach does not have a terminal emulation layer, and passes the raw output stream of the program to the attached terminals. The only input processing that dtach does perform is scanning for the detach character (which signals dtach to detach from the program) and processing the suspend key (which tells dtach to temporarily suspend itself without affecting the running program), and both of these can both be disabled if desired.

Contrary to screen, dtach has minimal features, and is extremely tiny. This allows dtach to be more easily audited for bugs and security holes, and makes it accessible in environments where space is limited, such as on rescue disks.

Thank you. I came here just to post about dtach too. It's my go-to thing for terminal detachment now; screen does WAY too much, and interferes with input to a ridiculous degree. The fact screen needs its own termcap is pretty unsettling. — fluffy, Sep 15 '11 at 18:12

score 9 · Answer 7 · edited Nov 26 '14 at 20:16

9

Here's a way to daemonize any shell process, no external programs needed:

( while sleep 5; do date; done ) <&- >output.txt &

When you then close your session, the job will continue to run as evidenced by the output.txt file (which has buffering so it takes a while to show non-zero). Don't forget to kill your job after testing.

So all you need to do is close stdin and background the job. To be really good, first cd / so you don't hold on to a mount.

This works even in simple sh under Solaris.

edited Nov 26 '14 at 20:16

Greg

167

answered Sep 16 '11 at 16:48

w00t

615

Interesting. That emerged some notable questions. I can see that you set the STDIN to nothing, the - operator? What is the difference between < /dev/null and &- ? I guess that STDIN (and others STDOUT and STDERR) could be assigned either a file by < file, or a stream by <& stream in case of STDIN. Would it be the same using < /dev/null in your example above? And Does the operator - above refer to a null as the stream? – doc_id Sep 16 '11 at 22:29
When you do x<&-, that closes file descriptor x. In this case there is no x, which makes bash default to 1, i.e. standard input. If you use </dev/null you're not closing stdin, you're just giving an empty file to the program as input. – w00t Sep 19 '11 at 17:15
1

And to be honest I don't really know why this daemonizes the thing you're running :-) It does work though, we use it in production. I discovered it while messing around hoping I could daemonize a process in shell without needing anything special - so I started by closing stdin and that was enough. I should go read some shell sources but I presume that if you close stdin and background the process, it also detaches the process. – w00t Sep 19 '11 at 17:19
2

I think the reason is that a SIGHUP (the actual signal that causes the child to quit when the shell dies) is triggered when a parent process closes its child's stdin handle. However, if stdin starts out as null, rather than being closed after the fact, there is no way for the parent to trigger the SIGHUP. Nice find, though — never would have thought of that. – Jeremy Visser Oct 15 '11 at 14:06
@JeremyVisser that sounds really plausible! – w00t Oct 17 '11 at 08:36
bash, ksh, csh, etc. are all job control shells. None of these require nohup for background jobs to continue running. If you are stuck with pre-Bourne UNIX shells then keep using nohup. – chicks Jun 22 '15 at 01:56

score 7 · Answer 8 · edited Nov 26 '14 at 20:05

byobu on Ubuntu is a nice front-end to screen. By pressing Ctrl-? you get a list of all the keyboard shortcuts. It adds a status bar that can be useful for watching CPU load, disk space, etc. Overall it provides an experience that I would describe as a terminal based VNC connection.

nohup allows starting a job in the background with its output routed to a log file, which can always be redirected to /dev/null if not required.

score 7 · Answer 9 · answered Sep 16 '11 at 08:23

The at command can be useful for this kind of situation. For example, type:

at now

And you can then enter a command or series of commands that will be run. The results should be e-mailed to you, if e-mail is set up correctly on the machine.

Instead of now, you can specify a time optionally with a date, or an time expression like now + 15 minutes. See man at for more details.

Keeping a linux process running after I logout

9 Answers9

Linked

Related