Added Support for killing flatpak FreeRDP

[Jacob-Friedberg]

Update winapps-launcher.sh to kill flatpaks
added support to kill freeRDP instances that are created from the flatpak version of freeRDP as it is one of the options on many winapps install guides. Normally when you ask the launcher to kill the freeRDP session it will not fully terminate flatpak instances. This leaves them open with odd behavior.

The code provided checks to see if flatpak is installed, then checks to see if FreeRDP is currently running as a process. If it is then it will kill it using the flatpak command. Otherwise the program continues as normal.

PID's provided as feedback appear to match the PIDS provided by flatpak PS on Kubuntu 24.04, so even if a flatpak process is killed this way the feedback will likely be accurate.

Depends on winapps-org/winapps#874

[oskardotglobal]

Please sign off the commit (see checks -> DCO for instructions). However, why did you PR this to the launcher and not to WinApps directly?

[Jacob-Friedberg]

It seemed like this was the proper place to add this functionality considering the KillFreeRDP button. I will talk a bit about why

I've been observing the process trees generated when using flatpak

here is the output from pstree -p

here is the output from ps -ef | grep winapps

in the ~/.local/share/winapps folder, the detected pid on the .cproc file for the freeRDP Process is 18369

When we go to kill the process using the KillFreeRDP button we see that it has attempted to kill the process.

looking back at the pstree we can see that the parent bwrap with pid 18369 and the parent winapps bash process were killed but has left its orphaned children to live on. This keeps the windows applications open, but in a non operable fashion.

using flatpak ps we can see that flatpak still thinks its alive.

using a flatpak kill cleans up the orphaned processes and closes the remaining window

This behavior does not exist with freerdp-nightly as the RDP_Command and the application and freerdp exit as expected. Additionally, and previously mentioned behavior solved for the case of a flatpak RDP_Command with the PR.

As for why not put in a PR to winapps directly, to be honest i dont know the code base well enough. I have spent a fair bit of time today becoming familiar with how things work, but it wasn't clear to me where an addition like this PR would be correct. Based on observing the winapps processes it seems to me that winapps and the xfreerdp session once launched won't terminate unless forced to by a crash or the KillFreeRDP button on the launcher. For example, if I open word and then close word it, I can still see the winapps process running in bash 10 minutes later along with xfreerdp3. Im not sure when or if it terminates normally so that a cleanup could occur like what happens when you KillFreeRDP. The one spot it can happen is for a SIGINT (CTRL + C) in the following snippet for winapps/bin/winapps

waCleanUp() {
    # Kill FreeRDP.
    [ "$FREERDP_PID" -gt 0 ] && kill -9 "$FREERDP_PID" &>/dev/null

    # Remove '.cproc' file.
    [ -f "${APPDATA_PATH}/FreeRDP_Process_${FREERDP_PID}.cproc" ] && rm "${APPDATA_PATH}/FreeRDP_Process_${FREERDP_PID}.cproc" &>/dev/null

    # Terminate script.
    exit 1
}

Additionally it seems like the behavior for winapps once running is to just wait until FreeRDP is terminated.

if [ "$FREERDP_PID" -ne -1 ]; then
        # Create a file with the process ID.
        touch "${APPDATA_PATH}/FreeRDP_Process_${FREERDP_PID}.cproc"

        # Wait for the process to terminate.
        wait $FREERDP_PID

        # Remove the file with the process ID.
        rm "${APPDATA_PATH}/FreeRDP_Process_${FREERDP_PID}.cproc" &>/dev/null
    fi

Based on my very shallow testing of just waiting and seeing, termination doesn't occur when applications are opened and then closed in winapps unless you use the KillFreeRDP button (this may be just expected behavior?). However, I should note that winapps does terminate when you launch Windows and then close out of the RDP window.

With all that being said, i think at least for now this PR should be put into the launcher to solve the incomplete termination of flatpak FreeRDP processes. I'm not sure how this would fit into larger topic of winapps but i would love to learn more about what you think

[KernelGhost]

@Jacob-Friedberg Thank you for your contribution. Your understanding of the project and the launcher is largely correct. I agree that your proposed addition belongs in the launcher, as it directly improves the behaviour of the “kill FreeRDP processes” button.

The behaviour you’re observing wherein full desktop RDP sessions terminate FreeRDP immediately, but RAIL application windows often leave the process running for several minutes is expected and originates from Windows rather than FreeRDP. In RAIL mode, Windows deliberately keeps the RDP session alive for a short period in case the user launches another application, avoiding the overhead of re-initialising the session and logging in again. This is governed by internal Microsoft heuristics. There may be some group policy settings that influence it, but the default behaviour is largely opaque.

Your PR looks mostly fine:

1. Please make sure you update the list of terminated process IDs. Your current changes don’t populate this.
2. I'm not sure why it is necessary to check for running processes within a subshell and to then subsequently check the overall exit status code. Would it not be more robust to use if flatpak ps | grep -q com.freerdp.FreeRDP; then?
3. It may make more sense to move your proposed code block above the existing for loop, ensuring the Flatpak FreeRDP process is terminated before running processes are queried.

Finally, as Oskar mentioned, commits need to be signed (git commit -s).

[KernelGhost]

@oskardotglobal Following your review, it would be best to merge this PR together with winapps-org/winapps#874, as both implement complementary changes to FreeRDP process lifecycle monitoring.

[KernelGhost]

@oskardotglobal FYI this PR now depends on the changes in winapps-org/winapps#874, so please hold off on merging until that PR is reviewed and merged.

[oskardotglobal]

@KernelGhost Got it. By the way, you can put a "Depends on <#id or link to an issue on another repo>" to have @dpulls block it automatically :)