Freerdp processes aren‘t terminated properly

[Tamyhen]

When trying to Pause, Hibernate, Power Off or Reboot the windows VM I receive the ERROR: Please ensure all FreeRDP instances are terminated. I tried using the built it Kill FreeRDP option yet I still receive the same error

Please help fix this issue. I am more than happy providing any debugging logs etc.

[Tamyhen]

Note that the application launcher and force kill does work fine

[Tamyhen]

It was functioning correctly after I first installed it. Rebooting the host system caused it to not work. I think it has to do with an incorrect connection with freeRDP port number. See the ports configuration in the compose.yaml file:
ports:
- 8006:8006 # Map '8006' on Linux host to '8006' on Windows VM --> For VNC Web Interface @ http://127.0.0.1:8006.
- 3389:3389/tcp # Map '3389' on Linux host to '3389' on Windows VM --> For Remote Desktop Protocol (RDP).
- 3389:3389/udp # Map '3389' on Linux host to '3389' on Windows VM --> For Remote Desktop Protocol (RDP).
cap_add:
- NET_ADMIN # Add network permission
WinApps was using port 4... instead of 3389

[Tamyhen]

Turns out you're supposed to run the winapps installer: bash <(curl https://raw.githubusercontent.com/winapps-org/winapps/main/setup.sh), in your home directory or else the user /.local/bin/winapps-src will not be detected and winapps will still install but with warnings about directories not being detected.

It is also possible that changing the $DOCKER_HOST variable to the podman.sock path:

find this with systemctl status --user podman.socket

Example:

export DOCKER_HOST="unix:///run/user/1000/podman/podman.sock"

Either way, winapps should update the README.MD to instruct users to run the installer in the home directory.

[KernelGhost]

@Tamyhen I’m having a bit of difficulty following exactly what you mean, but it sounds like you may have resolved the issue. Regarding your suggestion to run the winapps installer from inside the user's home directory, my understanding of setup.sh is that the install script doesn’t depend on the directory it’s executed from. Could you please confirm whether the launcher is now working as expected for you? If not, would you mind providing clearer reproduction steps? At the moment it’s hard to tell which of these problems is still an issue.

[KernelGhost]

Closing due to inactivity after four months without follow-up. Please reopen if this is still an issue.

[Maxb0tbeep]

Hello, sorry to revive a dead issue, (a week after it was closed ): ) but I'm having identical symptoms. I can open applications and force power off, but pause, hibernate, normal power off, etc, do not work and show the same popup as the original post.

I've also tried running query user in the container terminal to see all RDP connections and then logoff <ID> for all listed to ensure that there are definitely no active connections

However, even after doing this, WinApps Launcher doesn't change.

Also, I don't have permission to reopen this issue so I am @-ing you now! @KernelGhost

[Maxb0tbeep]

I figured out why it was doing this. I had a file called FreeRDP_Process_104909.cproc in ~/.local/share/winapps/ which persisted through reboots, docker restarts, etc. My best guess of how this happened is that I rebooted my computer with a FreeRDP process open and it didn't get properly closed. So, this is technically my fault but I think it isn't a super great way of checking if there's an active connection.

It might be good to have the kill_freerdp() function remove corresponding .cproc files after killing the processes. I'm happy to fork and make a PR with this if someone who knows what they're talking about agrees that it's a good idea.

TLDR: rm ~/.local/share/winapps/FreeRDP_Process_* (close any real connections first)

[KernelGhost]

@Maxb0tbeep An orphaned FreeRDP_Process_*.cproc file would explain why pause, hibernate and power-off were not working. That said, I don’t think the launcher is the right place to add cleanup logic. The launcher shouldn’t be mutating WinApps’ internal state or modifying files used for its own process tracking. Lifecycle management should remain the responsibility of the component that creates the .cproc files, rather than being delegated to what is intended to be a complementary launcher application.

waCleanUp is an existing function in bin/winapps that attempts to remove .cproc files when WinApps is terminated via Ctrl+C. However, this logic would be skipped in cases such as a system reboot whilst WinApps is running. A more robust solution would be to extend this mechanism to also run on script startup, allowing any orphaned .cproc files to be cleared before normal execution begins.

[Maxb0tbeep]

I agree that it shouldn't be in the launcher. I wasn't really thinking clearly, sorry. Having WinApps remove orphaned .cproc files on startup seems like the best option to fix this.