Gfrktyl

I know about nohup and it won't do what I want:

Example:

$ nohup sleep 600 2>/dev/null >/dev/null </dev/null&

[1] 21844

$ ps -ef | fgrep -e 'sleep

> TTY'

UID        PID  PPID  C STIME TTY          TIME CMD

me       21844 19313  0 09:37 pts/9    00:00:00 sleep 600

As you can see, sleep still has pts/9 as a controlling terminal. I don't want it to have any controlling terminal. Partly because the program I want to use (it isn't sleep if you haven't guessed) tries to open the controlling terminal to ask me questions and I want to see how it behaves if it can't. How do I make this happen?

This is a FreeBSD solution, but perhaps a similar technique will work for your OS.

I know cron isn't exactly the command line, but if you have a specific command list you want to run, cron can do that. You'll likely want to avoid having cron run the job repeatedly, perhaps by crafting a wrapper around your desired command list, something like:

#!/bin/sh

[ -f /tmp/my-semaphore-file ] || {

  touch /tmp/my-semaphore-file

  my_command_stack > /dev/null 2>&1

}

Inelegant perhaps for production use, but if you just want to test how your command stack performs with no controlling terminal, that will do it. The wrapper will not allow cron to run the command again until you:

rm /tmp/my-semaphore-file

at(1) is also an option, and is "almost" a command-line solution:

echo 'my_command_stack > /dev/null 2>&1' | at now+1 minute

You need to also use disown to detach the process from the tty.

https://unix.stackexchange.com/questions/3886/difference-between-nohup-disown-and

Try running nohup sleep 600 2>/dev/null >/dev/null </dev/null& disown and see if that gives you the desired result.

As far as I can tell, the answer to this question is that you can't do this from the command line on most Linux distributions.

Doing this in Unix/POSIX/Linux in general is possible, but requires a very specific sequence of system calls involving multiple processes. And an explanation of why and how would require explaining things at the code level, which I don't think is appropriate for superuser.

And while there used to be command lines tools that would do this (I think daemonize was one of them) they do not seem to be widely distributed anymore. At least, Fedora doesn't package them. One of the reasons why is likely because this has interesting implications from the standpoint of things like systemd which have a notion of a user session quite apart from the process groups and session ids that traditional terminal oriented job control has typically relied on.