Remmina quits silently after closing RDP or main Remmina window

I have had a problem with Remmina for the past three weeks.

I have started Remmina by using: remmina -i
It is then placed in the system tray correctly.

I'm working normally, start RDP and close the connection, the whole Remmina app closed with it.

If I start for example the main Remmina window and close the window, Remmina is closed with it.

But if I will keep the main Remmina window opened, start RDP and close RDP connection, Remmina is still active correctly, because the main Remmina window is still open.

It seems there is some problem with the window handles, and wrong mapping that no window is present, the Remmina main thread is killed, or something like this.

It happens on all my workstations, 10 computers.

No error present in output.

org.remmina.Remmina - 1.4.20 (git n/a) 5.13.13-arch1-1 awesomewm

This is because we have deprecated XEmbed, a protocol deprecated by Gtk and Wayland.

Try an application indicator like Ayatana .

Unfortunately we cannot do anything and probably in the future we will remove completely the remmina icon because of the directions taken with/by GNOME and Wayland

closed

I don't understand. What is ayatana indicator? I'm using awesomewm.

If I try to start remmina from console, without parameter -i. The behavior is same, the application quit after closing any window, or RDP connection.

Or which mode of remmina I have to use?

In the meanwhile read this

https://gitlab.com/Remmina/Remmina/-/wikis/Problems-and-tweaks/Systray-menu

Later I'll give you more details, now I'm quite busy

It was a long day, sorry.

Without considering the Remmina icon, the normal behavior is what you have described.

When you close the last remote connection, the Remmina main window, that is the window where you have the connection profiles list, closes as well. This can be seen as a weird functionality, but it's how has been implemented many years ago based on many users request.

The remmina icon, that explains the weird behavior, if enabled, not only provides a bunch of nice functionalities, but it prevents Remmina to close in the above mentioned scenario, so that it can be reopened from the systray.

Even if you have AwesomeWM (as I use i3wm), I'm quite sure you have a (system tray) bar that shows applications icons, like remmina. Usually that icons are embeded in a small container, using the XEmbed protocol.

This protocol exists only in XOrg, as in Wayland, they say for security reasons, it hasn't been implemented, and so the Gtk team, that never liked application icons (application indicators), took profit of this to deprecate application indicators as a whole, and some of them pushed really hard to force us to remove it as well.

TopIcons, appindicator, Ayatana and others came later to re-add the support through XEmbed and other mechanism.

So, what I can say more, it's quite a mess, we have spent many hours trying to find a solution and personally I didn't find any, but using appindicator, that is compatible with Ayatana and topicons.

Just installing appindicator (better ayatana if you can!) it should solve your issue, if it doesn't either you have a version of appindicator that fallbacks to XEmbed, or there's a bug in the system tray you are using, but in any case, as far as I know, there's no other solution than living with this till we will implement the remmina icon fnctionalities somewhere else.

Patches are welcome!! For the pleasure or to prove I'm wrong (that it can always be!)

Edit: corrected some of the hundreds typos

I found Ayatana in AUR and compiled it successfully. What I have to configure to work it with remmina? Thanks.

Restarting it it should work.

See in the wikI, there's a debugging page. When you start in debug in the first lines you will see if appindicator is supported or not

Thanks for help.

I tried ayatana, and debug, but the log are not available in ~/.cache dir. I tried to check settings, but it seems that it is not activated, and it is reason that there are no logs from ayatana libs. In wiki there is no info or description. I have to look to internet comments, maybe I will find some solution, but it takes large time...

Thanks for help.

https://gitlab.com/Remmina/Remmina/-/wikis/Usage/Remmina-debugging

Just follow the link...

Start remmina from a terminal as described and paste here the result

I expect that it will be this line:

** (org.remmina.Remmina:124469): DEBUG: 07:59:05.812: (remmina_icon_init) - StatusNotifier/Appindicator support: not supported by desktop. libappindicator will try to fallback to GtkStatusIcon/xembed

remmina full log output (not ayatana - this log missing):

~ ➜ G_MESSAGES_PREFIXED=all G_MESSAGES_DEBUG=all remmina
** (process:124469): DEBUG: 07:59:05.725: (remmina_pref_init) - periodic_rmnews_last_get set to 1597441016
(process:124469): GLib-GIO-DEBUG: 07:59:05.729: _g_io_module_get_default: Found default implementation gvfs (GDaemonVfs) for ?gio-vfs?
Load modules from /usr/lib/remmina/plugins
Remmina plugin glibsecret (type=Secret) has been registered, but is not yet initialized/activated. The initialization order is 2000.
Remmina plugin kwallet (type=Secret) has been registered, but is not yet initialized/activated. The initialization order is 1000.
** (process:124469): DEBUG: 07:59:05.753: (remmina_plugin_entry) - gfx_h264_available: 1
The glibsecret secret plugin  has been initialized and it will be your default secret plugin
(process:124469): GLib-DEBUG: 07:59:05.769: unsetenv() is not thread-safe and should not be used after threads are created
(org.remmina.Remmina:124469): GLib-GIO-DEBUG: 07:59:05.809: _g_io_module_get_default: Found default implementation dconf (DConfSettingsBackend) for ‘gsettings-backend’
(org.remmina.Remmina:124469): dconf-DEBUG: 07:59:05.809: watch_fast: "/org/appmenu/gtk-module/" (establishing: 0, active: 0)
(org.remmina.Remmina:124469): dconf-DEBUG: 07:59:05.809: unwatch_fast: "/org/appmenu/gtk-module/" (active: 0, establishing: 1)
(org.remmina.Remmina:124469): dconf-DEBUG: 07:59:05.809: watch_fast: "/org/appmenu/gtk-module/" (establishing: 0, active: 0)
(org.remmina.Remmina:124469): dconf-DEBUG: 07:59:05.809: watch_established: "/org/appmenu/gtk-module/" (establishing: 1)
(org.remmina.Remmina:124469): dconf-DEBUG: 07:59:05.809: unwatch_fast: "/org/appmenu/gtk-module/" (active: 1, establishing: 0)
(org.remmina.Remmina:124469): dconf-DEBUG: 07:59:05.809: watch_established: "/org/appmenu/gtk-module/" (establishing: 0)
(org.remmina.Remmina:124469): GLib-DEBUG: 07:59:05.810: unsetenv() is not thread-safe and should not be used after threads are created
(org.remmina.Remmina:124469): Gtk-DEBUG: 07:59:05.810: Connecting to session manager
(org.remmina.Remmina:124469): Gtk-DEBUG: 07:59:05.810: Failed to get the GNOME session proxy: The name org.gnome.SessionManager is not owned
(org.remmina.Remmina:124469): Gtk-DEBUG: 07:59:05.810: Failed to get the Xfce session proxy: The name org.xfce.SessionManager is not owned
** (org.remmina.Remmina:124469): DEBUG: 07:59:05.812: (remmina_icon_init) - StatusNotifier/Appindicator support: not supported by desktop. libappindicator will try to fallback to GtkStatusIcon/xembed
** (org.remmina.Remmina:124469): DEBUG: 07:59:05.826: (remmina_pref_init) - periodic_rmnews_last_get set to 1597441016

(org.remmina.Remmina:124469): Gtk-WARNING **: 07:59:05.844: gtk_menu_attach_to_widget(): menu already attached to GtkMenuItem
** (org.remmina.Remmina:124469): DEBUG: 07:59:05.865: (remmina_main_init) - Initializing the Remmina main window
** (org.remmina.Remmina:124469): DEBUG: 07:59:05.933: Name com.canonical.AppMenu.Registrar does not exist on the session bus

(org.remmina.Remmina:124469): dconf-DEBUG: 07:59:05.933: watch_fast: "/org/appmenu/gtk-module/" (establishing: 0, active: 0)
(org.remmina.Remmina:124469): dconf-DEBUG: 07:59:05.933: unwatch_fast: "/org/appmenu/gtk-module/" (active: 0, establishing: 1)
(org.remmina.Remmina:124469): dconf-DEBUG: 07:59:05.933: watch_established: "/org/appmenu/gtk-module/" (establishing: 0)

(org.remmina.Remmina:124469): Gdk-CRITICAL **: 07:59:06.101: gdk_window_thaw_toplevel_updates: assertion 'window->update_and_descendants_freeze_count > 0' failed
** (org.remmina.Remmina:124469): DEBUG: 07:59:08.814: (rmnews_periodic_check) - remmina_pref.periodic_news_permitted is 0
** (org.remmina.Remmina:124469): DEBUG: 07:59:20.823: (rmnews_periodic_check) - remmina_pref.periodic_news_permitted is 0
** (org.remmina.Remmina:124469): DEBUG: 07:59:32.824: (rmnews_periodic_check) - remmina_pref.periodic_news_permitted is 0
** (org.remmina.Remmina:124469): DEBUG: 07:59:44.828: (rmnews_periodic_check) - remmina_pref.periodic_news_permitted is 0
** (org.remmina.Remmina:124469): DEBUG: 07:59:56.831: (rmnews_periodic_check) - remmina_pref.periodic_news_permitted is 0
** (org.remmina.Remmina:124469): DEBUG: 08:00:05.815: (remmina_pref_save) - Setting periodic_rmnews_last_get to 1597441016
** (org.remmina.Remmina:124469): DEBUG: 08:00:08.835: (rmnews_periodic_check) - remmina_pref.periodic_news_permitted is 0
** (org.remmina.Remmina:124469): DEBUG: 08:00:20.847: (rmnews_periodic_check) - remmina_pref.periodic_news_permitted is 0
** (org.remmina.Remmina:124469): DEBUG: 08:00:32.855: (rmnews_periodic_check) - remmina_pref.periodic_news_permitted is 0
** (org.remmina.Remmina:124469): DEBUG: 08:00:44.856: (rmnews_periodic_check) - remmina_pref.periodic_news_permitted is 0

Yes, right, it's what I was expecting. So the only solution you have is to switch to a different bar for awesome .

I personally use polybar with I3, I don't know if it may suit you tho

I try to discuss it with awesomewm devs. Maybe they find some solution. I have to use standard awesome bar and tray integration, we have a lot of staff implemented in lua. Thanks

@raven2cz If you're using a distro with systemd, you're welcome to do the same stupid thing I did when I started experiencing this issue (Fedora 33/Cinnamon, tray icon shows up at startup or when started with -i but remmina kills itself when the last visible window is closed): Disable built-in "Start in tray on user login" option; Create a unit file ~/.config/systemd/user/remmina.service

[Unit]
Description=Remmina applet

[Service]
Type=exec
ExecStart=/usr/bin/remmina -i
Restart=always

[Install]
WantedBy=default.target

Then it's just systemctl --user enable remmina.service and systemctl --user start remmina.service

This way it will start remmina in tray when you log in and restart it immediately after it closes itself because there's no active windows left.

changed title from Remmina app quit silently after closing RDP or main remmina window to Remmina quits silently after closing RDP or main Remmina window

changed the description

added DEAwesomeWM PluginsRDP bug labels

Nice workaround, mainly usage of user service without root privileges. In awesome, I keep opened main main window minimized in first tag, but sometimes I forget and the app is closed...this is better variant.

I stumbled on this thread while searching why Remmina closed its main window after disconnecting an RDP connection (I don't use the tray icon and I don't want to). If I understand correctly, it's the intended behavior. For my workload it's a very annoying feature. Can this be made an option which I could disable ?

I also tried with the tray icon, and the behavior is the same : the main window is closed after RDP disconnect, AND the tray icon is killed too (even if it was manually started with remmina -i). So there is absolutely no way to keep the main window opened. I think this is a bug, as it started to behave this way some months ago, but I'm pretty sure it used to work as I expected.

Also, I'm not sure if it's related (but I strongly suspect it is), if you configure actions to be taken before/after connecting, Remmina quits before it runs the exit action. This is really a problem. If you're sure it's not related, I can of course open a new issue.

Any help would be appreciated. Thanks :)

@MoonSweep after remmina receive a connection close signal, remmina exits only if THREE conditions are true

if (remmina_widget_pool_count() < 1 && !remmina_main_get_window() && !remmina_icon_is_available()) {
  close remmina
}

Which means that: there must be no other open connection AND there must be no main window visible AND there must be no appindicator/systray icon visible. The "main window" is the window with the list of all profiles.

If you think that one of the three condition is not satisfied (i.e.: your main window is still visible on the screen when you close your last RDP connection) but remmina closes, then you can be affected by a crash of remmina. Please run remmina inside a terminal window and copy and paste here the last lines 20-40 of output after remmina closes unexpectedly. Also please let us know which version of remmina you are running, this is very important. And which desktop/window manager you are using.

Hi, and thanks for caring of my problem !

This is with Remmina 1.4.1 from Debian Stable (but it was made DFSG-free, I don't know what they removed). The desktop is Gnome 3.38. I have the app-indicator extension loaded and running, and I enabled the applet for the test. And you didn't ask it, but the server is xrdp (but I have the same problem with other servers using freerdp2-shadow-x11 to connect to a session opened locally).

Also, to be perfectly clear, the remote desktop doesn't close unexpectedly, I do close it manually ; it's the main window which closes unexpectedly.

Here is the log:

Before connection:

raph@solaris:~$ LANG=C remmina
Load modules from /usr/lib/x86_64-linux-gnu/remmina/plugins
Remmina plugin glibsecret (type=Secret) has been registered, but is not yet initialized/activated. The initialization order is 2000.
The glibsecret secret plugin  has been initialized and it will be your default secret plugin
StatusNotifier/Appindicator support: your desktop does support it and libappindicator is compiled in Remmina. Good.
Running under GNOME Shell version 3.38.6

(org.remmina.Remmina:717129): Gtk-WARNING **: 15:36:48.133: gtk_menu_attach_to_widget(): menu already attached to GtkMenuItem

After connection:

[15:36:56:097] [717129:717155] [WARN][com.freerdp.crypto] - Certificate verification failure 'self signed certificate (18)' at stack position 0 
[15:36:56:098] [717129:717155] [WARN][com.freerdp.crypto] - CN = [redacted]
[15:36:57:203] [717129:717155] [INFO][com.freerdp.gdi] - Local framebuffer format  PIXEL_FORMAT_BGRX32
[15:36:57:203] [717129:717155] [INFO][com.freerdp.gdi] - Remote framebuffer format PIXEL_FORMAT_BGRA32
[15:36:57:203] [717129:717155] [INFO][com.freerdp.channels.rdpsnd.client] - [static] Loaded fake backend for rdpsnd
[15:36:57:203] [717129:717155] [INFO][com.freerdp.channels.drdynvc.client] - Loading Dynamic Virtual Channel rdpgfx
[15:36:57:204] [717129:717155] [INFO][com.freerdp.channels.drdynvc.client] - Loading Dynamic Virtual Channel disp

Closing:

[15:37:07:763] [717129:717155] [ERROR][com.freerdp.core] - freerdp_abort_connect:freerdp_set_last_error_ex ERRCONNECT_CONNECT_CANCELLED [0x0002000B]
free(): invalid next size (fast)

Also, I have forgotten about this, but at around the same time than stop actions stopped working, Remmina sometimes exit unexpectedly right after connecting, and I need to reconnect several times before I can get a desktop... In those cases, the error message in the log is corrupted size vs. prev_size.

Thanks again ! :)

Hi again...

I just recompiled the source package from Debian unstable (1.4.27) to stable and all the problems I mentioned are gone. It was probably a bug in 1.4.11 which was fixed a long time ago.

Sorry for the noise.

That being said, it would be interesting to find the origin of the bug, and produce a small patch for 1.4.11, since it can be easily integrated in the next point release, and benefit all Debian stable users, whereas a complete backport of 1.4.27 (even in the official repositories) must be installed manually and would benefit only a small portion of users; but I would understand if you don't want to waste time on an old bug.

I have still this bug with remmina 1.4.27 and I have to use workaround described up. I don't know details of implementation, this is still problem with just remmina. Any next apps work correctly. Ayatana cannot be used with awesomewm and it is not correctly supported anymore, so it is not solution.

I'm surprised that remmina process is not close on your system with 1.4.27 version. It seems that there are used another standards against i3, awesome and others. The problem still remains for awesome.