Let's first look at what happens if a program is started from an interactive shell (connected to a terminal) without & (and without any redirection). So let's assume you've just typed foo:
The process running foo is created.
The process inherits stdin, stdout, and stderr from the shell. Therefore it is also connected to the same terminal.
If the shell ...
My favorite solution is using tmux, you could detach the session, and re-attach it in another terminal.
When you detached from previous session, you can safely close the terminal; later use tmux attach to get back to the session, even if you logged out.
nohup and disown -h are not exactly the same thing.
With disown, a process is removed from the list of jobs in the current interactive shell. Running jobs after starting a background process and running disown will not show that process as a job in the shell. A disowned job will not receive a HUP from the shell when it exits (but see note at end).
To detach a process from a bash script:
nohup ./process &
If you stop your bash script with SIGINT, or the shell exits sending SIGHUP for instance, the process won't be bothered and will continue to execute normally. stdout & stderr will be redirected to a log file: nohup.out.
If you wish to execute a detached command while being able to see the ...
The parent process id (ppid) of a process cannot be changed outside of the kernel; there is no setppid system call. The kernel will only change the ppid to (pid) 1 after the processes parent has terminated - if the process did not respond to a signal that the parent was terminated. For this to happen, the process needs to have ignored various signals (...
When you press Ctrl+Z in a terminal, this causes the foreground process group to receive the signal SIGTSTP (assuming the terminal is in cooked mode and the default key bindings are in place). If the process hasn't set a signal handler for SIGTSTP, this causes the process to be suspended (and even if the process has set a signal handler, it usually only does ...
Having a global keybind to disown the foreground process is impossible: Keystrokes are received by the foreground process, not by the shell. You need to first suspend it with Ctrl+z if you want to disown it.
However, turns out there's a zsh option to speed up disowning then continuing: With setopt AUTO_CONTINUE, disown will automatically also send SIGCONT.
The problem is that you are using both & and ; together. They are both command terminators, and can not be used at the same time. Here is your example fixed:
( cd /opt/myprogram && ./myprocess.sh >/dev/null 2>&1 & disown )
The fact that a process is "disowned" has only a meaning for the interactive shell that created this process. It means that the shell doesn't include (anymore) the process in its jobs table, and that SIGHUP will not be sent to this process when the shell exits. It is not really related with your questions.
About what happens to the outputs that are sent to ...
"injcode" from ThomasHabets seems to be exactly the thing I need:
The injcode program allows arbitrary code to be injected into a running
process, whether or not you knew beforehand and were running screen or tmux
From the README:
Example 1: move irssi from one terminal to another
Maybe move it into a ...
If you just want to pause it and restart afterwards, you can use kill with STOP or CONT signal.
At first find out the processes PID with
$ ps aux
Then send the signals to that PID listed to the process
$ kill -STOP <PID>
$ kill -CONT <PID>
Here is my experience trying to run soffice in the background, following a non-terminating command (e.g. tail). For this example I will use sleep 100.
/opt/libreoffice4.4/program/soffice -invisible -nofirststartwizard &
I see soffice logs / by pressing Ctrl-C soffice stops
nohup .. &
For the rare person who, like me, both had this problem and finally managed to google for something that wasn't about baseball* and want an actual solution:
$ play whatever.wav &>/dev/null </dev/null &
That runs in the background without stopping.
* The Red Sox of Boston play baseball, and apparently some players prefer the limelight to the ...
bash, zsh and ksh93 are the shells that have a disown command. Of the three, bash is the only one that supports a h option. Without -h it emultates zsh behavior (remove from the job table), while with -h it emulates ksh93 behavior (will not send it a SIGHUP upon exit, but doesn't remove it from the job table so you can still bg or fg or kill it).
You could ...
disown only removes a job from the table of active jobs (maintained by the shell), ensuring that the corresponding process isn’t killed when the shell terminates. It doesn’t change the I/O setup given to the process (standard input, output and error); so the disowned job’s output still goes to the terminal where it was started, or to wherever it was ...
Likely, your shell is not bash but dash which doesn't have disown. Do fgrep $(id -n) /etc/password and see whether your shell is bash. If it's not, then update it, re-login, and you will be able to disown processes.
If you want to continue using the current shell (which lacks the disown builtin) you can use nohup your_command_here & to achieve almost ...
Invocation of reptyr is sufficient to detach the terminal, but has to be
sudo reptyr -T $PID
From man reptyr:
Use an alternate mode of attaching, "TTY-stealing".
In this mode, reptyr will not ptrace(2) the target process, but will attempt to discover he terminal emulator for that process' pty, and steal the master end of the pty.
Without -h the job is removed from the table of active jobs, with -h it is not.
Everything is in the manual:
disown [-ar] [-h] [jobspec ...]
If the -h option is given, each jobspec is not removed
from the table, but is marked so that SIGHUP is not sent to the
job if the shell receives a SIGHUP.
To see the difference ...
Processes backgrounded via bg or & will typically die under 2 scenarios:
The shell receives a SIGHUP
They try to write to a terminal which no longer exists.
Item #1 is the primary culprit when closing your terminal. However whether it happens or not depends on how you close your terminal. You can close it by:
Something like clicking the "X" in your ...
disown on its own is sufficient to let the program keep running after you disconnect:
zsh: suspended command_running_forever
 + continued command_running_forever
 + running command_running_forever
$ disown %1
disown -h uses a bash argument which causes the job to remain on the job table and ...
Just to address this specific question:
If I close the virtual terminal, where some process was started, does the output just go straight to /dev/null, or can it pollute memory somehow?
The terminal and the program(s) connected to it communicate via a tty device by reading and writing it like a file. Specifically, a virtual terminal creates a "pseudo-tty"...
They are Different:
disown removes the job from the active jobs table. Then continues on with current job. With -h the proccess is NOT sent SIGHUP. It is instead left to die with the shell that contains it, when it recieves a SIGHUP.
nohup ignores the HUP. Then anything that would have been passed to the terminal by the proccess closing instead goes to a ...
To answer the most interesting part of your question: to change the output of a live running program, you have to edit its file descriptors. That is quite easy to do with gdb. It's a hack, but works.
A helper script is available at ...
Basically it looks like you need a flexible (just an app, not a whole desktop) X session through ssh that you can resume at any time.
I use NX for that. I've also used during some time x2go, but I always come back to NX.
Some links worth to look at:
And a couple of ...
It's a little hard to diagnose, as you don't give source for myproc, but I suspect that your problem has something to do with "controlling TTY". I wrote a small shell script that just calls sleep 100. I ran it under nohup:
$ nohup ./sleeper > sleeper.out &
+ Running nohup ./sleeper > sleeper.out &...
So what does the man page tell us about huponexit?
If the huponexit shell option has been set with shopt, bash sends a SIGHUP to all jobs when an interactive login shell exits.
EDIT: Emphasizing that it is a LOGIN shell.
EDIT 2: interactive deserves equal emphasis
In general, it isn't possible for a shell to “adopt” a job. For a shell, a job means a few things:
Associate a job identifier with a process ID.
Display its status (running, suspended, dead).
Notify the user when the status changes.
Send a SIGHUP signal when the terminal goes away.
Control whether the job “owns” the terminal (whether it's the foreground ...