session: Become subreaper & end children upon finish

[palinek]

This is another approach to "correctly stop all children upon session exit":

1. upon start become a subreaper (a process which become a parent of its descendants if its immediate parent ends)
2. upon session finish send TERM to all children processes and give them a bit time to finish gracefully

This logic is currently implemented only for Linux (proper if/ifdefs used), but based on goole-fu, there are possibilities to implement this for BSD also
https://stackoverflow.com/questions/62365978/get-a-list-of-child-processes-from-parent-process-in-c-and-c-cross-platform
https://unix.stackexchange.com/questions/149319/new-parent-process-when-the-parent-process-dies

@jsm222 Could you have a look for the BSD changes?

[tsujan]

I only found some time to test it quickly on my old laptop. I did the tests with FeatherPad, by launching it from lxqt-panel, pcmanfm-qt and by using keyboard shortcut (lxqt-globalkeys) and leaving its window open when logging out. In all three cases, it was terminated correctly on logout (and saved what it should have saved to its config file). Very nice!

[tsujan]

The code is good too. I'd like it to be in 0.17 if there's no objection.

[palinek]

I'd like it to be in 0.17 if there's no objection.

No objection from my side (of course :) )

I just changed the sleep interval in ProceReaper thread...as there is no need to wake so often, when we use the waitcond and wake the thread instantly upon finish

$ git diff
diff --git a/lxqt-session/src/procreaper.cpp b/lxqt-session/src/procreaper.cpp
index 7c7512c..bb92196 100644
--- a/lxqt-session/src/procreaper.cpp
+++ b/lxqt-session/src/procreaper.cpp
@@ -31,7 +31,7 @@ void ProcReaper::run()
         if (pid <= 0)
         {   
             QMutexLocker guard{&mMutex};
-            mWait.wait(&mMutex, std::chrono::milliseconds(200));
+            mWait.wait(&mMutex, std::chrono::seconds(1));
         }

         int status;

[tsujan]

.... as there is no need to wake so often

200 ms didn't have a tangible effect here but, yes,1 sec seems better.

[palinek]

There was even next typo with variable hiding :( ... fixed

$ git diff
diff --git a/lxqt-session/src/procreaper.cpp b/lxqt-session/src/procreaper.cpp
index bb92196..a8a56b8 100644
--- a/lxqt-session/src/procreaper.cpp
+++ b/lxqt-session/src/procreaper.cpp
@@ -35,7 +35,7 @@ void ProcReaper::run()
         }

         int status;
-        pid_t pid = ::waitpid(-1, &status, WNOHANG);
+        pid = ::waitpid(-1, &status, WNOHANG);
         if (pid < 0)
         {   
             if (ECHILD != errno)

[luis-pereira]

Tested in Linux. It performed as described.
@palinek Consider adding a license notice in each source file.

[palinek]

Consider adding a license notice in each source file.

Done.

[palinek]

Should I merge this?

[tsujan]

Should I merge this?

Please do! It's good news for 0.17.

[yan12125]

This breaks applications that are expected to live longer than the GUI session (e.g., tmux).

Steps to reproduce:

1. Run qterminal from within LXQt (click the quicklaunch button in my case)
2. Run tmux
3. Detach the tmux session. Now the tmux server is a sub-process of lxqt-session. Here are partial outputs of pstree:

        │                        └─lxqt-session─┬─
        │                                       ├─tmux: server───zsh

4. Log out of the LXQt session

Expected result: the tmux session persists and can be attached later

Actual result: the tmux session is gone

[tsujan]

@yan12125
Any reason that you didn't open an issue?

[palinek]

How can the session distinguish which process is supposed to live longer than the GUI session?
Either we should implement some mechanism to leave particular children untouched upon ending session or the user should run such processes outside of session.

[tsujan]

How can the session distinguish which process is supposed to live longer than the GUI session?

It can't, unless there's an "inside info" somewhere.

The problem might be avoided if we can add a method for the user to exclude some apps in a new section of LXQt Session Settings. Also, a few apps may be excluded in the code. Just a vague suggestion...

[yan12125]

Any reason that you didn't open an issue?

Argh, possibly because I was sleepy. Created #376.