What's the difference between "-dm" and "-Dm" in GNU Screen?

The GNU Screen manual says:

    `-d -m'
          Start `screen' in _detached mode. This creates a new session
          but doesn't attach to it. This is useful for system startup

    `-D -m'
          This also starts `screen' in _detached_ mode, but doesn't fork
          a new process. The command exits if the session terminates.

-dm is pretty clear to me:

  • screen forks a new process to run the provided command (or a shell if nothing was specified).
  • By "fork" it means that weird Schrödinger’s system call in which the source code doesn’t know if it’s the parent or the child until the return value is observed.
  • And this new process is recognized by screen as something that can be attached.

I noticed that -dm returns control of the shell, but -Dm blocks.

So my question is:

  • Why does -Dm block? And how is that related to its lack of forking?
  • What does it do instead of forking? I think it still creates a new process, because "detached mode" suggests a process identifiable by a PID which can be attached.
  • What’s the use case of -Dm instead of -dm?


Asked By: Sebastian Carlos


In the quoted context of the screen documentation, you can read "to fork a new process" as "to start a new child process". At the risk of heading sideways too far, here’s how you can consider the process to work. To create a child, a process must use fork(2). That child process runs freely from the parent, and the child exists to exec(2) the command that’s to run from the parent. The parent can choose to –

  1. call wait(2) for the child process to complete, which means it will block until the child exits and will then receive the exit status back from the wait(2) call
  2. continue on its way until it receives the SIGCHLD signal notifying it that the child has exited, and at this point call wait(2) to receive the exit status
  3. exit without caring about the child, in which case the process’s parent will become the new parent of the child process

Now, with that in mind, here’s how it applies to screen.

Usually you would want screen -dm to create a new (child) process and detach from it, allowing your own command execution to continue. For example, this could make sense in ~/.profile or the older system-wide /etc/rc.local where you would not want a command to block. In this case the child process described above is actually another part of screen, which in turn kicks of the real command process as yet another child (a grandchild of the original parent). The two parts of screen communicate, and the child instance of screen manages its command child that does the work you really want.

Occasionally you might want to use screen under control of a supervisor such as systemd. In this instance you would use screen -Dm so that the supervisor could identify if/when the process managed by screen had exited, possibly with the intent of restarting it. If screen had detached the child process – as it would with screen -dm – the supervisor would not be able to tell easily if it was still running or not; the -Dm flags allow screen to provide all its features to the child process while still communicating its existence to the parent. In this case the middle process (the child screen) is not created and the screen parent directly controls the command child that does the work you really want.


  1. screen -dm sleep 30 – your interactive shell that started the screen command cannot tell whether or not the sleep 30 is still running. There is no feedback.
  2. screen -Dm sleep 30 – your interactive shell blocks until the sleep 30 exits. At this point you know it is no longer running. Clearly not so useful for an interactive session but it’s excellent for a supervisor environment such as systemd.
Answered By: roaima