Delay when logging off Ubuntu GNOME #160
Comments
|
Hi, epoptes-client is a shell script, it's not using GTK3 or clutter or anything like that.
|
|
I tried both. If I just wait a minute and don't do anything except log on
and off quickly we still get the delay. However, when I removed the
.desktop file from /etc/xdg/autostart I do not get the delay.
I also checked that with that file removed, I could still see the machine
in epoptes (i.e., on the machine we have the server running).
…On Thu, Jul 21, 2022 at 1:32 PM Alkis Georgopoulos ***@***.***> wrote:
Hi, epoptes-client is a shell script, it's not using GTK3 or clutter or
anything like that.
Please try the following and mention if you still see the logout delay:
1. If you login, wait 1 minute, then logout without running anything
at all, do you still get the delay?
2. If you remove /etc/xdg/autostart/epoptes-client.desktop, then
reboot/login etc, do you still get the delay?
—
Reply to this email directly, view it on GitHub
<#160 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ANJXBC53UP5WWVOHARA2CQLVVGCTHANCNFSM54IB5PIQ>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
|
If a student pkills epoptes-client to block the teacher from contolling them, epoptes-client is smart enough to try to re-launch itself. Patches welcome; personally I don't use GNOME anywhere as it has a whole lot of other problems, but I might try to have a look in time for Ubuntu 24.04! :D |
alkisg
changed the title
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
We are using Ubuntu 20.04 (non-LTSP) and when we go to logoff the computer (not through epoptes, but regular logoff), it takes a long time(more than a minute or 2) to return to the login screen. We verified that both the client and the server versions of epoptes are 20.04. This seems to be an issue with epoptes because when we remove epoptes, we don't see the slowness. I am attaching a snippet of our syslog when we log off the machine as well as a blog post related to clutter and gtk3 (found at this site: https://blogs.gnome.org/clutter/)
From the blog
If you are maintaining a GTK3 application using Clutter, Clutter-GTK, and Clutter-GStreamer, I strongly recommend you move to libadwaita, GTK4 and to GStreamer.
From our syslog -- the client
Jul 21 11:20:41 cs-132 gnome-shell[3787]: Object Meta.BackgroundActor (0x5629803af650), has been already deallocated — impossible to access it. This might be caused by the object having been destroyed from C code using something such as destroy(), dispose(), or remove() vfuncs.
Jul 21 11:20:41 cs-132 gnome-shell[3787]: JS ERROR: Error: Argument 'instance' (type interface) may not be null#012_init/GObject.Object.prototype.disconnect@resource:///org/gnome/gjs/modules/core/overrides/GObject.js:571:24#012_onDestroy@/usr/share/gnome-shell/extensions/desktop-icons@csoriano/desktopGrid.js:209:45#012_init/<@/usr/share/gnome-shell/extensions/desktop-icons@csoriano/desktopGrid.js:148:44
Jul 21 11:20:41 cs-132 gnome-shell[3787]: == Stack trace for context 0x56297e7bf720 ==
Jul 21 11:20:41 cs-132 gnome-shell[3787]: #0 7fff1b8ce1d0 b resource:///org/gnome/gjs/modules/core/overrides/GObject.js:571 (2d7b713b6c40 @ 25)
Jul 21 11:20:41 cs-132 gnome-shell[3787]: #1 562981c0a4a0 i /usr/share/gnome-shell/extensions/desktop-icons@csoriano/desktopGrid.js:209 (2eeecb509ad8 @ 85)
Jul 21 11:20:41 cs-132 gnome-shell[3787]: #2 562981c0a418 i /usr/share/gnome-shell/extensions/desktop-icons@csoriano/desktopGrid.js:148 (2eeecb5098f8 @ 12)
Jul 21 11:20:41 cs-132 gnome-shell[3787]: Attempting to call back into JSAPI during the sweeping phase of GC. This is most likely caused by not destroying a Clutter actor or Gtk+ widget with ::destroy signals connected, but can also be caused by using the destroy(), dispose(), or remove() vfuncs. Because it would crash the application, it has been blocked and the JS callback not invoked.
Jul 21 11:20:41 cs-132 gnome-shell[3787]: The offending signal was destroy on Gjs_ui_iconGrid_IconGrid 0x56298186db50.
Jul 21 11:20:41 cs-132 gnome-shell[3787]: == Stack trace for context 0x56297e7bf720 ==
Jul 21 11:20:41 cs-132 gnome-shell[3787]: message repeated 4 times: [ == Stack trace for context 0x56297e7bf720 ==]
Jul 21 11:20:41 cs-132 gnome-shell[3787]: Attempting to call back into JSAPI during the sweeping phase of GC. This is most likely caused by not destroying a Clutter actor or Gtk+ widget with ::destroy signals connected, but can also be caused by using the destroy(), dispose(), or remove() vfuncs. Because it would crash the application, it has been blocked and the JS callback not invoked.
Jul 21 11:20:41 cs-132 gnome-shell[3787]: == Stack trace for context 0x56297e7bf720 ==
Jul 21 11:20:41 cs-132 gnome-shell[3787]: The offending signal was destroy on Gjs_ui_iconGrid_IconGrid 0x5629819f2d00.
Jul 21 11:20:41 cs-132 gnome-shell[3787]: Attempting to call back into JSAPI during the sweeping phase of GC. This is most likely caused by not destroying a Clutter actor or Gtk+ widget with ::destroy signals connected, but can also be caused by using the destroy(), dispose(), or remove() vfuncs. Because it would crash the application, it has been blocked and the JS callback not invoked.
Jul 21 11:20:41 cs-132 gnome-shell[3787]: The offending signal was destroy on Gjs_ui_appDisplay_AppIcon 0x5629817ef150.
Jul 21 11:20:41 cs-132 gnome-shell[3787]: Attempting to call back into JSAPI during the sweeping phase of GC. This is most likely caused by not destroying a Clutter actor or Gtk+ widget with ::destroy signals connected, but can also be caused by using the destroy(), dispose(), or remove() vfuncs. Because it would crash the application, it has been blocked and the JS callback not invoked.
Jul 21 11:20:41 cs-132 gnome-shell[3787]: == Stack trace for context 0x56297e7bf720 ==
Jul 21 11:20:41 cs-132 gnome-shell[3787]: message repeated 3 times: [ == Stack trace for context 0x56297e7bf720 ==]
Jul 21 11:20:41 cs-132 gnome-shell[3787]: The offending signal was destroy on Gjs_ui_appDisplay_AppIcon 0x5629817ef150.
Jul 21 11:20:41 cs-132 gnome-shell[3787]: == Stack trace for context 0x56297e7bf720 ==
Jul 21 11:20:41 cs-132 gnome-shell[3787]: message repeated 3 times: [ == Stack trace for context 0x56297e7bf720 ==]
Jul 21 11:20:41 cs-132 gnome-shell[3787]: Attempting to call back into JSAPI during the sweeping phase of GC. This is most likely caused by not destroying a Clutter actor or Gtk+ widget with ::destroy signals connected, but can also be caused by using the destroy(), dispose(), or remove() vfuncs. Because it would crash the application, it has been blocked and the JS callback not invoked.
Jul 21 11:20:41 cs-132 gnome-shell[3787]: == Stack trace for context 0x56297e7bf720 ==
Jul 21 11:20:41 cs-132 gnome-shell[3787]: message repeated 3 times: [ == Stack trace for context 0x56297e7bf720 ==]
Jul 21 11:20:41 cs-132 gnome-shell[3787]: The offending signal was destroy on Gjs_ui_iconGrid_BaseIcon 0x562981a39ae0.
Jul 21 11:20:41 cs-132 gnome-shell[3787]: == Stack trace for context 0x56297e7bf720 ==
Jul 21 11:20:41 cs-132 gnome-shell[3787]: message repeated 4 times: [ == Stack trace for context 0x56297e7bf720 ==]
Jul 21 11:20:41 cs-132 gnome-shell[3787]: Attempting to call back into JSAPI during the sweeping phase of GC. This is most likely caused by not destroying a Clutter actor or Gtk+ widget with ::destroy signals connected, but can also be caused by using the destroy(), dispose(), or remove() vfuncs. Because it would crash the application, it has been blocked and the JS callback not invoked.
The text was updated successfully, but these errors were encountered: