Good morning everyone!

The default when we run a program from the terminal is that the PID of the program is the child of the terminal, i.e. we have 2 programs running!

Is it possible to run a program on the terminal, freeing the terminal and the PID of this program is not a child of the terminal?

yes and no. All the programs started from anywhere will be the child of that initiator process (called parent/and child). There is no exception.
Just a remark: the parent process is not the terminal, but the shell running inside the terminal. The terminal process itself (usually) is the parent of that shell.
From the other hand you can detach the child process from the terminal (and parent) using &:
In this case you will get your prompt (and shell) back and also the program will run in the background.
https://linuxconfig.org/bash-backgro...ess-management

2 members found this post helpful.

No. It remains attached
Right

You must use command like nohup or screen to detach a program from the terminal where it was launched

1 members found this post helpful.

Is there a possibility the running shell in the terminal to not be child of the terminal?
Or terminal not be the parent of that running shell?
Thats something I will like to learn... thank you.

Maybe search for informations about programming a daemon (although running a shell with no input and output is questionable)

I am not sure I fully understand what you are trying to do.

All processes have a parent. (well except init or you can think of its parent as the kernel). To detach from the controlling terminal and by extension the terminal emulator that hosting it, in the case of xterm and similar a process can become a daemon. This essentially re-parents it to pid 1 - init. In this case the the chains of terminals emulators/shells/etc that eventually created that process can terminate without daemon terminating. The simplest thing as marv mentioned is probably using screen. The recipe there is -

screen -S 'Friendly Name for your Session' -dm -s /path/to/your/application

You can even implement a daemon in common scripting languages like python and ruby - actually both make it fairly simple to do. Similarly both offer the ability to create virtual PTYs in their standard library where you run another process and essentially have io objects you can read and write for stdin/stdout/stderr. You could write a script to create PTY, spawn your process do what you need to do with the standard FDs and demonize, if you don't want to use screen for some specific reason.

The definition (or meaning) is quite simple, the process which starts another process is the parent, and the new one is the child. In the linux world every process has a parent process (obviously the one which started it). There is only one exception, the very first process has no parent. But if you really want to learn just look for a correct description, what I wrote here is just the first step to start with.
The terminal emulators by default start a program to work with (inside the terminal), it can be a shell or something else, but it is always started by the terminal and also if the program exits the terminal itself will exit too. But again you need to learn about it, this is just an overview.

2 members found this post helpful.

Hi,

Did you try this?

disown probably won't solve the problem. If the terminal is a PTY (xterm and similar) vs an actual con device, when the PTY goes away the process will likely crash as soon as it tries to use stdin/stdout/stderr. Another choice might be the nohump. However that does not provide much control as compared with screen, but certainly is lighter weight.

Actually I don't know what should be solved here.

I believe it is just a typo, the command should be

My guess is that the "real" problem not is the fact that the process (bash) which starts another proces (for example xclock) becomes the parent of that process. The problem was probably that the prompt did not return until the child process terminated. The solution, as others have pointed out is to start the child as a background process with "&" after the command.

If you from bash or any other shell (in a terminal or from console) start a process but forget the "&" all hope is not lost. You can get your prompt back by temporary stopping the child process, that is done by pressing "ctrl-z". Now, with you prompt back, you have three options:

1. Keep the child process stopped
2. Type "fg" to get the child process in the foreground, stealing the prompt again
3. Type "bg" to put the child process running in the background, keeping your prompt

However, if the problem really should be that the new process becomes a child of the parent process, there is a trick to avoid that. That trick is to start an extra process, then the process you don't want as your own child and finally kill that extra process which is the parent of the child process. When the parent dies the child process becomes orphaned. All orphaned processes are adopted by the init process (pid 1). Example:

regards Henrik

5 members found this post helpful.

Interesting. I have a handful of bash scripts and apps in "~/.config/autostart" and I'm pretty sure none of them retain the child/parent relationship. That said though I did notice that recently with upgrade to 15.0 something auto adds "--damonize" to "/usr/bin/conky" when I add it into KDE's system-settings Autostart. It doesn't alter scripts though.

pstree is useful to see relationships

3 members found this post helpful.

It's the default .desktop in the sources