view · edit · print · history

There are many different reasons and situations you may want to keep your current terminal activity or execution running. Luckily, there are more than one way of managing the process or application.

  • nohup, disown and standard job control
  • dtach
  • screen (GNU screen)

nohup and Standard job control

About nohup

nohup is a command preventing the subsequent executing command from receiving some system Signals such as HANGUP - hence NOHUP = no hangup. It's commonly used with the shell's standard job control since the execution will still occupy the executing prompt, for example, the ampersand to background a task. By default, all the stdout console output is redirected to nohup.out unless you redirect it yourself.

This is fine for most situations not requiring user interaction or response.

Building and Installation

The nohup binary is normally included with even the most minimal unix like systems. With Optware, SlugOS or Debian, it's part of the coreutils package.

Usage examples

   nohup cmd & # stdout is redirected to nohup.out

   nohup cmd > std.out 2> std.err &

   ps -fu username # will show your processes not attached to any shell. 
                   # Important for tracking down nohup processes to kill.

Tips and Suggestions

  • Learn to use your shell's job control such as `fg`, `bg` and & ( read your shell's manpage and check your docs )
  • Learn to use Signal control

bash disown

$ help disown
disown: disown [-h] [-ar] [jobspec ...]
    By default, removes each JOBSPEC argument from the table of active jobs.
    If the -h option is given, the job is not removed from the table, but is
    marked so that SIGHUP is not sent to the job if the shell receives a
    SIGHUP.  The -a option, when JOBSPEC is not supplied, means to remove all
    jobs from the job table; the -r option means to remove only running jobs.

Additional References


About dtach

dtach originated as a minimalist alternative to screen. It allows you to spawn a shell or other command into its own detachable pseudo-terminal. It also allows you the ability to share your session with a cohort. It can be used anywhere from large corporate style servers to the lovable NSLU2 Slugs.

  • It doesn't interpret or intercept anything except a couple of control keybindings (Ctrl+\ , Ctrl+Z, Ctrl+L). Luckily, a couple of switches allows you to re-assign those controls and manage your attach/detachment.
  • It's small in size and load. After stripping an i386 build, it was only 10K !! Heck, the manpage is 5K.
  • Because it uses Unix sockets (as opposed to network sockets), security is controlled using regular file permissions and is localized to the box. Your secure connection is your problem. :-)
  • dtach let's you share the session. Ever try to troubleshoot over the phone using VNC or worse, MS Netmeeting, just for console stuff? (Screen can do this too)
  • It has no library dependencies so you can manually unpack and install your own personal copy in ~/bin if it's not installed on the system.

Now, you can return to interactive session of `mc`, Vim, or a compile, etc. no sweat. (Try a long compile on the Slug?)

In fact, this is probably the most extensive article you'll come across about using dtach. Most people use screen before realizing dtach is just enough - that is if they find out about dtach at all.


If you are using Optware, just issue the command: ipkg install dtach

If you are using SlugOS, you have two options:

  • install the Optware feed (I did) and issue the command: /opt/bin/ipkg install dtach
  • compile, package and install your own version

If you're using Debian, apt-get install dtach will install it

If you're using a major distro on your desktop, it should be found in your distro's repository

Building and Installation

If you want to compile, package and install your own version (untried for Slug)

the build on a regular RHES Linux box for personal use was: ./configure; make; strip dtach; cp dtach ~/bin ; # as not to pollute the /usr/bin or /usr/local/bin system using `sudo make install`


Example one - a standard, detachable Bash session

This example launches a dtach session. If the unix socket exists, attach to it, otherwise create a new session/socket and execute bash.

  dtach -A /tmp/mydtachsocket -z bash

Then to detach from your session you could just close your terminal application or you can press the default Ctrl+\ .

Example two - a sharable Bash session

Say you don't care about a detachable session, but you want to share a Vi session with a co-worker in the same user group. No problem.

  1. dtach -A /tmp/myvisession -z vi log-or-filename
  2. in vi, issue the command - :!chmod 660 /tmp/myvisession (NOTE: I couldn't get 640 to work for me)
  3. have your all your peers connect using: dtach -a /tmp/myvisession # now everyone can work the file or log

Now both you and you co-worker can work together on the same file, seeing the same thing. The best part is, you don't have to restart your session - instant gratification - if you start out using dtach.

You can try it out on from a couple of terminals on the same workstation without having to change permission, it's freaky cool. Just dtach -A /tmp/mydtachsocket -z bash in multiple consoles.

Example three - backgrounding like nohup

  dtach -c /tmp/bgdtach -z myscript

Make sure your script or command redirects it's output someplace else for review. It doesn't cache stdout & stderr for you. You would have to attach to see them if not captured.

Other Examples or situations

This list could be really long. It's up to you to try some out. Please add your suggestions and ideas at the end of the page. Many of these are applicable to screen as well.

  • if you use WiFi connectivity which has a flaky connection, dtach (and screen) is a godsend
  • sharing the same terminal from multiple machines around the house
  • sharing troubleshooting screens, logs, etc
  • long compiles or installs
  • console based apps which need to stay "alive" like: irc or other IM clients/bots, bittorrent, etc.
  • your console based PIM, calendar, media clients, dashboards, etc
  • a console place holder or session manager - you've got to leave for work and want to return where you left off. Let it sit there idle.

Gotchas and idiosyncrasies

  • Using Ctrl+D to log out. This traditionally will send the HANGUP signal to your shell which then closes out the dtach session. Get ready to say "doh" ... it'll break you from that convenient habit. And it's embarrassing when giving a presentation or working in a classroom environment. BTW, remapping 'd' as your dtach key doesn't work either, I tried. :-)
  • Using Ctrl+Z to suspend a job. By default, dtach will accept that Ctrl+Z and suspend _itself_, thank you very much - not. You can turn off that annoying feature using the'-z' switch.
  • Using Ctrl+L to refresh. Works great. However, if your console GUI app doesn't refresh right away, it gets "wonky", Ctrl+L will clean it up. However, it may take longer for the app to resize itself to match your terminal. You can control the refresh method. Definitely look over it's manpage and dtach --help. There's not much too it. I discovered this using Midnight Commander `mc` ftp'ing some files.
  • NOTE: dtach hasn't really been updated since 2004. It hasn't been ported to many POSIX systems, for example AIX, as they have different psuedo-terminals.
  • UPDATE: dtach has now reached 0.8 Jan 30, 2008.

Tips and Suggestions

  • Read the minimal docs and experiment. There's other ways to control the refresh/redraw, re-mapping the detach key, etc.
  • Make a ~/dtach or ~/.dtach to store all your dtach sessions/unix sockets and use it. Check it for lingering sessions
  • Give your dtach socket handles sensible names. Heck, close a session and create a new one if you change major tasks
  • Make some aliases for instant dtach terminals or frequent commands.
  • Come up with some prompt magic to keep yourself informed of when you're using `dtach` and which Unix Socket it's on.
  • Create some scripts so that your login shell becomes a pre-dtached bash shell - like a dtach manager.
  • Use -c create when issuing ssh remote commands if you need to revisit it later (ssh user@host "dtach -c ~/dtach/taskname ScriptOrConsoleApp")

Additional References

screen (GNU screen)

About GNU screen

What's there to say? It's the granddaddy of screen multiplexers. It was written years ago in the age of dial-up to allow multiple consoles over a single terminal connection. It's still being actively developed and advanced today.

dtach is a 1-to-1 session manager. Screen takes over terminal management. It's highly configurable. Instead of re-hashing the many articles on screen, you can check out some links at the end of this post. And yes, screen allows you to share screen with others. It's a switch and managed differently than dtach.

Unfortunately, you may end up with a hand cramp if you're managing several screen screens/tab at a time. Everything is Ctrl+Key CommandKey combo sequence.

What's probably more important: I've noticed screen slurping up a lot of memmory (up to 1MB if I've read the numbers correct), and because you'll be running a sh or bash inside it, that takes _another_ 400-500K for every window inside screen.. Be aware of this if you're planning to use this on small-memmory devices like the NSLU2.

Installation (much like dtach)

If you are using Optware, just issue the command: ipkg install screen

If you are using SlugOS, you have two options:

  • install the Optware feed (I did) and issue the command: /opt/bin/ipkg install screen
  • compile, package and install your own version

If you're using Debian, apt-get install screen will install it

If you're using a major distro on your desktop, it should be found in your distro's repository

Building and Installation

Someone feel free to point to an article on how to build it from source.


Simply invoke: screen

It will start screen, load a shell and drop you into it. You can exit it by exiting the shell (just type 'exit', and screen will close too). You can detach it by pressing Ctrl+A D You'll be returned to the non-screened shell, and the process running in screen will continue running in the background.

To re-attach to a screen session, enter: screen -R You'll return to your screen session jus where you left it. (however, if there's more than one screen running then it will give you a list of screens to attach to)

Inside the 'screen', there are various commands you can use: To create a new screen, press Ctrl+A C. You can do this any number of times.

To switch between screens, press Ctrl+A #, where # is 0 through 9.

To close a screen, just log out. Note, just because you close 2, doesn't shift 3, 4 & 5 down. #2 is freed up, that's all.

Example one - Create a detached screen session. Then attach to it later (from User Contributions)

The following screen command will create a new screen session:

screen -dmS midnight mc
  • '-d -m' means: start screen in "detached" mode. This creates a new session but doesn't attach to it. This is useful for system startup scripts, so you can use this in /etc/rc.local to run anything in the background;
  • '-S midnight' means: sets the screen-name to 'midnight', so if you're running multiple screens you can easily find and re-attach to it, instead of guessing the screen number;
  • 'mc' tell screen to start the command 'mc' (midnight commander, if you've installed it).

To attach to this screen, enter: screen -R midnight

Gotchas and idiosyncrasies

(there's more than this)

  • `screen` uses Ctrl+A by default for console switching. Bash however uses Ctrl+A to jump to the start of the line. This can be adjusted.
  • It intercepts quite a bit.
  • the session management is via the keyboard. It's no problem for those used to keyboard. (rhetorical) But how one scroll lines up and down without scrollbars after `cat`ing a file?
    • You don't need scollbars. Press Ctrl-A followed by [Esc] then you can scroll up and down the virtual screen with the cursor keys and you can even select and copy text. Press [Esc] again and you are back to where your cursor was.

Tips and Suggestions

  • Read the man page. It's big.
  • You'll probably created a custom ~/.screenrc file. Many styles include "tabs", clocks, hostname, and other notables. Searching the internet for screenrc will turn up more than enough.

Additional References

User Contributed Tips, Examples, URL references, etc.

The wall of shame. Feel free to shout out your tips and examples here so we can keep the above article from having 50 tips and examples in each section. Thanks.


nohup Tips

In the bit where it says:

  • Learn to use your shell's job control such as `fg`, `bg` and & ( read your shell's manpage and check your docs )

I'd like to share how I use the slug to download large files via ftp so that I don't have to have my main computer on.

  1. . ssh to the slug as per normal.
  2. . $ ftp ftp.desired.server.org
  3. . Navigate to the desired area and get or mget the file(s) you want, this will start the download.
  4. . Type <CTRL>z
  5. . It should say something like:
              [1]+  Stopped                 ftp ftp.desired.server.org
  1. . Starts the process in the background $ bg 1
  2. . It should say something like:
              [1]+ ftp ftp.desired.server.org &
  1. . Type ls -al a few times to ensure that the file you are downloading is getting bigger over time. If it is, it's working!
  2. . Exit your ssh session. If you like, you can ssh back in again to try step 8. just to ensure that it's working.

If you need to kill the ftp process for whatever reason, list all processes via: ps -ax If the ftp is running and shouldn't be, killall ftp or if it's not responding, killall -9 ftp

How I use nohup


dtach Tips

How I use dtach


screen Tips

  • The following screen command will create a new session if none exists, detach a session if remotely attached, and (re)attach to it.
screen -AadR

How I use screen

view · edit · print · history · Last edited by MarkStinson.
Based on work by BrianZhou, Fred, bla, asdf, MarkStinson, markstinson, fcarolo, and cbase.
Originally by markstinson.
Page last modified on June 13, 2008, at 11:44 AM