Gnome-shell-system-monitor-applet: Problems with relogin after sleep/screensaver in Gnome when extension is enabled

[jankatins]

When I used this app, I sometimes had to wait 10-15 seconds after I put in my password after sleep/screensaver. Sometimes, even the password screen wouldn't vanish at all and I had to restart X. If the login was successful (after the ~10sec wait), the bar charts were empty / just starting to get new values (not sure if this is by design: https://github.com/paradoxxxzero/gnome-shell-system-monitor-applet/issues/329). This happened on two Laptops I set up (ubuntu 16.10 + debian stretch).

I tried to debug this but couldn't find anything suspicious in the journal. The problem went away after I disabled the system monitor extensions.

Do you have any way how I can get more information out of the extension?

[franglais125]

I use Debian Stretch too, but I don't have this problem. What other extensions do you use?

To get more info: sudo journalctl /usr/bin/gnome-shell. For instance when I login I get these messages:

Apr 03 11:45:42 debian gnome-shell[1407]: JS LOG: System monitor applet enabling
Apr 03 11:45:42 debian gnome-shell[1407]: JS LOG: System monitor applet enabling done

As for the graphs being empty when you login, yes, this is the way it works!

[ghost]

Re-installed the extension (via the extension page in Chrome) and left it running during a meeting -> gnome had a screensaver open and after I typed in my password, the page was agin stuck. Switched to the console and looked into the journal and found this:

Apr 10 11:17:29 PC-SUJ gnome-shell[23990]: JS LOG: System monitor applet disable
Apr 10 11:25:03 PC-SUJ gnome-shell[23990]: JS LOG: System monitor applet enabling

-> it didn't show a 'done' message and after 5 minutes I killed the gnome session (killall -3 gnome-session) and tried a a restart of the xserver but I couldn't get my relogined. So I delete the extension again and rebooted and that worked.

[chrisspen]

@jan-schulz-k24 Did you install the extension from extensions.gnome.org or from master on github? If not from github, please try installing master. There are a few pending changes to support the most recent Gnome version that I haven't pushed up to the extensions website.

[jankatins]

On my other computer, I got this (still the same version of extensions.gnome.org):

Apr 10 09:34:28 littlebottom2 gnome-shell[1511]: JS LOG: System monitor applet disable
Apr 10 21:33:48 littlebottom2 gnome-shell[1511]: JS LOG: System monitor applet enabling
Apr 10 21:34:08 littlebottom2 gnome-shell[1511]: JS LOG: System monitor applet enabling done

-> It also took ~ 20 seconds to from password+enter to getting to the desktop :-/.

[franglais125]

Two questions that might help all of us:

• What other extensions do you use? Since I'm on Debian stretch too, I can install whatever else you have and see if I can reproduce it.
• As @chrisspen suggested, do you mind trying the git version? You can download from git and run make && make install.

[jankatins]

I've now installed from master, lets see what happens...

I've the folloing other extensions installed:

• https://extensions.gnome.org/extension/302/windowoverlay-icons/
• https://extensions.gnome.org/extension/602/window-list/
• https://extensions.gnome.org/extension/1031/topicons/
• https://extensions.gnome.org/extension/234/steal-my-focus/
• https://extensions.gnome.org/extension/750/openweather/
• https://extensions.gnome.org/extension/517/caffeine/
• https://extensions.gnome.org/extension/15/alternatetab/

I use debian stretch and ubuntu 16.10 with gnome instead of unity.

[franglais125]

Ok, let us know if you encounter the same problem with the git version.

As for your extensions, I installed them all and I don't see a problem. Does it happen immediately, or does it take some time? I tried locking/unlocking quite a few times without any issue.

[jankatins]

I usually encounter it after I let the laptop stand alone for a meeting or food. As far as I remember it didn't happen when I do a simple logout+login.

[jankatins]

And another one with latest master:

Apr 11 21:16:13 littlebottom2 gnome-shell[1511]: JS LOG: System monitor applet disable
Apr 11 21:53:58 littlebottom2 gnome-shell[1511]: JS LOG: System monitor applet enabling
Apr 11 21:54:18 littlebottom2 gnome-shell[1511]: JS LOG: System monitor applet enabling done

[franglais125]

One thing I didn't think of asking is how you have configured the extension. What elements are displayed on the top bar, and what are the timeouts for each one of them? Maybe a few screenshots can help.

If the enabling starts but never finished, perhaps one of the elements blocks the process.

I'm really trying on my end, but I can't reproduce the issue still.

[jankatins]

I display CPU, memory and net (graph + tooltip) and as far as I know, I haven't changed anything on the refresh times (I haven't found any 'timeout' setting?!).

In the above it starts and finishes ('enabling done'), but simply blocks my login (from password+enter to being able to interact wih the desctop takes the ~20sec).

[jankatins]

I added more logging:

Apr 12 19:24:46 littlebottom2 gnome-shell[1511]: JS LOG: System monitor applet disable
Apr 12 19:48:26 littlebottom2 gnome-shell[1511]: JS LOG: System monitor applet enabling
Apr 12 19:48:26 littlebottom2 gnome-shell[1511]: JS LOG: System monitor: mounts...
Apr 12 19:48:46 littlebottom2 gnome-shell[1511]: JS LOG: System monitor: cpus...
Apr 12 19:48:46 littlebottom2 gnome-shell[1511]: JS LOG: System monitor: freq...
Apr 12 19:48:46 littlebottom2 gnome-shell[1511]: JS LOG: System monitor: mem...
Apr 12 19:48:46 littlebottom2 gnome-shell[1511]: JS LOG: System monitor: swap...
Apr 12 19:48:46 littlebottom2 gnome-shell[1511]: JS LOG: System monitor: net...
Apr 12 19:48:46 littlebottom2 gnome-shell[1511]: JS LOG: System monitor: disk...
Apr 12 19:48:46 littlebottom2 gnome-shell[1511]: JS LOG: System monitor: termal...
Apr 12 19:48:46 littlebottom2 gnome-shell[1511]: JS LOG: System monitor: fan...
Apr 12 19:48:46 littlebottom2 gnome-shell[1511]: JS LOG: System monitor: battery...
Apr 12 19:48:46 littlebottom2 gnome-shell[1511]: JS LOG: System monitor: done...
Apr 12 19:48:46 littlebottom2 gnome-shell[1511]: JS LOG: System monitor: here1...
Apr 12 19:48:46 littlebottom2 gnome-shell[1511]: JS LOG: System monitor: here2...
Apr 12 19:48:46 littlebottom2 gnome-shell[1511]: JS LOG: System monitor: here3...
Apr 12 19:48:46 littlebottom2 gnome-shell[1511]: JS LOG: System monitor: after build_menu_info...
Apr 12 19:48:46 littlebottom2 gnome-shell[1511]: JS LOG: System monitor: after change_usage...
Apr 12 19:48:46 littlebottom2 gnome-shell[1511]: JS LOG: System monitor: after menu.connect...
Apr 12 19:48:46 littlebottom2 gnome-shell[1511]: JS LOG: System monitor applet enabling done

The code between mount and cpu is this:

        log('System monitor: mounts...');
        MountsMonitor.connect();

        // Debug
        Main.__sm = {
            tray: new PanelMenu.Button(0.5),
            icon: new Icon(),
            pie: new Pie(Style.pie_width(), Style.pie_height()), // 300, 300
            bar: new Bar(Style.bar_width(), Style.bar_height()),  // 300, 150
            elts: [],
        };

        // Items to Monitor
        log('System monitor: cpus...');

[franglais125]

Awesome, this is exactly what I was going to ask you next (maybe providing you with a debug branch).

My general feeling now is that this is something specific to your system:

• Are your partitions available? The extensions looks for these: /, /home, /tmp, /boot, /usr, /usr/local
• Do you have network attached storage?

To see exactly where the extension blocks, I think you could add a few more logs in the refresh function, of the smMountsMonitor class.

[jankatins]

here is my mountoutput:

sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
udev on /dev type devtmpfs (rw,nosuid,relatime,size=5989116k,nr_inodes=1497279,mode=755)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /run type tmpfs (rw,nosuid,noexec,relatime,size=1200180k,mode=755)
/dev/sda5 on / type btrfs (rw,relatime,ssd,space_cache,subvolid=5,subvol=/)
securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k)
tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755)
cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/lib/systemd/systemd-cgroups-agent,name=systemd)
pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime)
cgroup on /sys/fs/cgroup/pids type cgroup (rw,nosuid,nodev,noexec,relatime,pids)
cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpu,cpuacct)
cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset)
cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory)
cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer)
cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio)
cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup (rw,nosuid,nodev,noexec,relatime,net_cls,net_prio)
cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,nosuid,nodev,noexec,relatime,perf_event)
cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=29,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=454)
mqueue on /dev/mqueue type mqueue (rw,relatime)
debugfs on /sys/kernel/debug type debugfs (rw,relatime)
hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime)
/dev/sda2 on /media/exchange type vfat (rw,relatime,fmask=0000,dmask=0000,allow_utime=0022,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro)
binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,relatime)
tmpfs on /run/user/119 type tmpfs (rw,nosuid,nodev,relatime,size=1200176k,mode=700,uid=119,gid=123)
tmpfs on /run/user/1000 type tmpfs (rw,nosuid,nodev,relatime,size=1200176k,mode=700,uid=1000,gid=1000)
fusectl on /sys/fs/fuse/connections type fusectl (rw,relatime)
gvfsd-fuse on /run/user/1000/gvfs type fuse.gvfsd-fuse (rw,nosuid,nodev,relatime,user_id=1000,group_id=1000)
/dev/sda1 on /media/js/Windows type fuseblk (rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096,uhelper=udisks2)
RStudio-1.1.139.glibc2.15-x86_64.AppImage on /tmp/.mount_FUaxyO type fuse.RStudio-1.1.139.glibc2.15-x86_64.AppImage (ro,nosuid,nodev,relatime,user_id=1000,group_id=1000)
KeePassXC-2.1.3-x86_64.AppImage on /tmp/.mount_O9bx0j type fuse.KeePassXC-2.1.3-x86_64.AppImage (ro,nosuid,nodev,relatime,user_id=1000,group_id=1000)
/dev/sda5 on /var/lib/docker/btrfs type btrfs (rw,relatime,ssd,space_cache,subvolid=5,subvol=/var/lib/docker/btrfs)

The appimages are on both systems, the ntfs one is specific to this system (there is a ntfs gnome vfs mount, too, but I only opened it twice I think and the problem happend more often).

[franglais125]

A possible solution to this would be to:

• Allow a maximum amount of time for the volumeManager to finish connecting
• Do the connection asynchronously, so that the login continues and the volumeManager gets updated whenever it finishes connecting

In any case, I'll wait for more info, if you can perhaps identify which partition is actually causing this?

[jankatins]

I would be strongly in favor of a async options, as I think even one second additional login time is somehow unacceptable -> IMO enable should be instant if it enabled after a simple login

[jankatins]

The problem seems to be related to the ntfs gnome vfs mount:

/dev/sda1 on /media/js/Windows type fuseblk (rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096,uhelper=udisks2)

I did a screen-lock + password and with that partition mounted it took 20 secs. After umounting it, log in time was ok again.

At work, I have a sshfs fuse mount. [Update] Just FYI: that is a mount which conntects via SSH to a server which is only available in a VPN. Sometimes the VPN would go down but the sshfs mount would not umount and that resulted in much problems overall (all ssh mounts now get umounted on vpn disconnect). It could be that in that this was resulting in the not-finishing login.[/]

[franglais125]

Ok, I'm glad we found the source of the problem!

If somebody with more experience in this specific part (e.g. Gio.VolumeMonitor) wants to weigh in, it would be greatly appreciated.

Otherwise, I can only think of doing this async. I can't promise I'll work on this soon, as I'll be away for the long weekend, and I'm too busy right now!

[Th3Z0ne]

I am affected by this same bug - it happens to me when the system was in suspend to ram and I have a fuse mount in nautilus.

My workaround so far - turn off everything that has to do with disk usage and partition capacity

[arigit]

1.5 years later, ubuntu 18.04 - still affected

[aquatix]

Same problem here, only recently found out it was caused by the applet. How can we help debug this further?

I don't see an option to completely disable showing disk (mountpoint) information; that would solve the problem for me, as I don't look at that information in the applet anyway.

[koenlek]

Same problem here. Having an option to disable disk info would be a fine solution for me too.

[arigit]

Same problem here, only recently found out it was caused by the applet. How can we help debug this further?

I don't see an option to completely disable showing disk (mountpoint) information; that would solve the problem for me, as I don't look at that information in the applet anyway.

did you try setting "Usage Style: none" in preferences > Disk? (and disabling display/show menu/show text)
I'm testing that and so far so good

[koenlek]

@arigit: thanks for the suggestion, but unfortunately that didn't solve the problem for me. Re-enabled the extension yesterday with all g "Usage Style: none" and all Disk checkboxes disabled (just to be sure) and had 3 occasions of hanging logins since. Without the extensions, everything works fine though

@franglais125 or @jankatins or @chrisspen : any time to implement the timeout or async option? If not, can you point me out what lines I should look at and I might consider trying to patch it myself.

[koenlek]

Good news, I went ahead and implemented a fix myself :) Seems to work fine for me now.

Hopefully it can soon be reviewed and released over official channels

[arigit]

@koenlek thanks! just removing all disk references did not solve the problem for me either. It did seem to decrease the frequency of hangs somewhat. Testing your PR now - will report back if the issue re-occurs

[koenlek]

@arigit how has my fix worked for you? Does it solve your problem too?

[arigit]

@koenlek Yes - the problem seems fixed, I haven't seen the issue again since implementing your patch. Hoping this will get merged soon to save the hassle to other users!

[koenlek]

That's great news :) Hoping it will soon get merged too

[lhotari]

It seems that this problem still exists. I was seeing 20-30 delays after relogin and disabling the system-monitor extension fixed the issue.
It looks like Shell.get_file_contents_utf8_sync is still used in a few places (disk, net) and there's an open issue for that (#496).

[return42]

As @lhotari mentioned, this thread is old, most of the problems have been resolved. Lets close this issue and follow #496.

@jankatins: if it is OK for you, can you please close this thread / thanks!