I'm not sure exactly what you're after, but in zsh there are a couple of ways to free the terminal after starting a program; "somecommand &" or "somecommand &!". With just "&" appended, the program is started in the background, but zsh gives you the job number and you can still do job control stuff with it. With "&!" appended, the program is disowned and not subject to job control. In either case, killing the shell will not kill the process that was started (I tested this by running "kwrite &" / "kwrite &!" in a terminal emulator and then killing the term).

The equivalent commands with bash seem to be "sommecommand &", which will background the program but still retain it in the job list, or "somecommand & disown" which seems to have the same effect as "&!" in zsh. The only difference I can see is with just "&" in bash, killing the starting shell does also kill the process that you started (which doesn't happen when you use disown).

How about "exec"? It causes the process to replace the given command. It's something you can see in rc scripts for example.

One can also achieve this using

1 members found this post helpful.

After 24h of debating on this subject
The real question is : where is the OP ?

And I agree with pan64

For some reason I do not see that difference on my system, maybe my bash has been configured differently.

What you are seeing is that some bourne-like shells when they die notifies their child processes that their parent is dying by sending a HUP signal. It is possible for a program to catch the HUP signal and do something else, but the default when a HUP signal is received is to die. If you have a bourne-like shell which sends HUP to its children when it dies and you want to let a background children keep living on you can start it with nohup:

As this thread is marked with "Advanced question" I might just as well continue to write some more about those signals used between processes. You might want to stop reading here unless you want to read a long horrific story about daemons and zombies...

As mentioned, the HUP signal is used to notify a process that its parent has died an that it should HangUP. The main reason for such a signal might be that the program has lost its stdout. However, there is also another common use for the HUP signal. Daemons providing different kinds of services like a mail server or a web server usually have the init process (pid 1) as their parent. In such a case you can be sure that the parent is not going to die before you and it is a rather common practice that those processes instead use the HUP signal to tell the process to reread its configuration files. In Slackware, you can see one such example in /etc/rc.d/rc.autofs where the HUP signal is used to tell the automounter daemon to reload its maps.

There are a number of signals, some, but not all signals are possible to catch and do whatever you like with. The INT (interrupt) signal is an example. A program will get that signal if someone presses ctrl-c in the terminal. By default, the the program will die when ctrl-c is pressed, but it is possible to write a program that does not die from the INT signal and instead chooses to do something else. However, it is not possible to catch the KILL signal, all processes has to die from the KILL signal.

If you want to read more about which signals there are you can read a man page:

Please note the 7 above, without any number:

You will instead get the lowest numbered signal man page

which describes how to write programs that catches signals.

So what about zombie processes? In Unix/Linux, a parent process has the right to know when a child process has died. The parent gets notified with a CHLD signal. However, with this right also comes a responsibility. The parent must make a wait call for the child to die. Unless that is done the child process will become a living dead zombie process.

Some parent processes think that they have more important things to do than waiting for dying child processes. If you write such a program, the responsible way to avoid waiting for dying child processes is to have them orphaned by forking an extra temporary process before the child process is started. When the extra process that started the child process exits, the child process becomes orphaned and gets adopted by the init process. The init process will let any dying process die in piece and zombie processes are avoided.

If you get a system with zombie processes you might note that it isn't possible to kill a zombie, it is already dead. The only way to get rid of those zombie processes is to kill the parents of the zombie processes.

regards Henrik

1 members found this post helpful.

There are people that do other things than spending all their time on this forum. In many parts of the world it is now holiday seasons. Maybe he wrote the question from work before going for a long weekend?

regards Henrik

1 members found this post helpful.

The question makes no sense as all terminals must have at least one child - this the one they're managing the input/output from. So for a terminal session that child will typically be 'bash' but it could be a specific programme like 'top'. So you can't replace 'agetty' or 'xterm' with 'bash' or anything else as such.

So probably the question is regarding a terminal session.

If you run a command in a session you will have terminal->shell->command. You can use exec to replace 'shell' with 'command', e.g. terminal->command, but that's the last thing you can run in that terminal (unless command has an exec function).

If the last command in a script is long running (e.g. an application or daemon start script) it should use 'exec' otherwise the initiating shell is hanging around doing nothing for no good reason.

You can 'detatch' a process from it's parent by doing a double-fork:

In pstree 'command' will no longer have a parent pid connected to the original terminal or shell.

This will spawn terminal->bash->bash->command, but the second bash will exit leaving command without a parent - the kernel will assign it a parent pid of 1 (init). There's a bit more to it regarding signals and file descriptors but that's the idea.

No you can't do that.

Read this:

https://xyproblem.info/

Then read this, which I suspect is what's being asked about:

https://www.tecmint.com/keep-remote-...disconnection/

Thank you, your answer was very helpful. I liked the link too!

In the test I did, when I exit the terminal, the program continues to run, and is no longer bound to the terminal. It is not even a child of the terminal anymore. In other words, I can run more than one program, close the terminal, and the programs will be running perfectly, without the link to the PID that no longer exists in the terminal!

What would be the difference in using only & or & disown
What would change?
When I run it for myself who has no knowledge, I see no difference!

nohup program
It doesn't work, if I close the terminal, the program closes too

I like this command! I found it very interesting! Thanks!

In bash it worked fine just using & i.e., terminating bash does not kill the child program!

1 members found this post helpful.

Thanks for the information!