Execute .sh script in a way that it keeps running after Qt programm has quit

I have a raspberry pi programm written wit QT5.8 opensource.
I wanted to give the user a possibility to update the program from source directly from the program itself.
The program is installed in "$/opt/PowerTune" the source code resides in "/home/pi/PowerTune"
i have written a sh script to update the program :

Unix: The started process will run in its own session and act like a daemon.

We don't know what code startDetached() uses under Linux, but I agree that explanation implies to me that the script should not itself get terminated....

Let's be clear about the behaviour you are actually seeing. You say:

My Problem now is that i oviously kill my program before deleting the install directory .

Deleting the install directory is the least of your problems. If you are right your script gets killed at the pkill -f PowerTuneQMLGui //Close my program before removing the install directory line. In that case it does not proceed to any further line at all, so it never does the qmake or reboot at all. Is that what you experience?

Well, we can conclude that startDetached does not really start as detached we might expect in this particular case.

I would assume that in the first case /bin/sh is started by the Qt application with an argument that happens to be a script-file (there is a lot of options to sh and bash, you might want to look into them).

In the second case a recognized executable program is started by the Qt application and the OS will figure out that it shall be interpreted using /bin/sh.

It will work the same on high level but might differ on the lower levels and as we are hunting some obscure reason to why startDetached does not actually start detached it might work different.

Another thing I have stumbled on is that the file of a started process can be overwritten while the already started process remains intact (well, loading dynamic libraries will not work well). I am not sure how this works on lower levels but when I stumbled on this it looked like the started version of the file was accessible from within the running program while any new process will use the new one. This was on the Solaris 2.6 age and might need to be verified for Linux ;)

The implication in this case is the started process will survive the script removing its files and one might consider not to kill the process at all as reboot will do that eventually which will solve the actual problem; successful rebuild and reboot

I wanted to give the user a possibility to update the program from source directly from the program itself.

But why? That's the one great thing about Linux distributions, that they all come with a unified install / update mechanism for all parts of the system. Why torture your users with a wacky home-grown updater?

@Markus-Ippy
Assuming you're still interested in pursuing the reason for this behaviour...

As I said, from the Qt docs on startDetached() I would have expected you sub-process not to get killed when the parent Qt app gets killed. I'm certainly interested if you are!

To find out what is going on, I would replace the content of your script with something like sleep 60 or similar. Set it off from within your app.

Now use ps with options to get all details about both your running app and the sub-process. I think ps -ejH will do it. (You will want to specify other options to reduce the number of processes shown or show more of the command-line to identify what is what, since you're writing scripts I imagine you can figure that.)

The column headers are at the top of the output: the first 3 are PID, PGID & SID. That's the ids for the process itself, the Group id & the Session id. What we need to know is whether your parent application and your sub-process child do or do not have same Group and/or Session ids, as this affects who signals delivered to the parent (your app) do or do not also get sent to.

If you fancy coming back with that information we would be in a starting position to understand what's going on to produce the behaviour you see!

The reason I use a logfile (wich I tail -f in another window) is that output is lost when the parent is killed and there are no indication beside ps to verify that the script-process is still alive. In general printouts from background processes may cause problems from time to time, better to log to a file.

The Qt C++ code cut from a public slot triggered by a button in a newly generated application:

P.S.
Since telling you to use ps to find out about running processes, I have now learned that Linux has the /proc pseudo-filing system for processes (didn't used to exist in my old UNIX days!). cattting "files" there reveals all sorts of interesting information about the process!