Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cinnamon DE takes a long time to load, .xsession-errors identifies xapp-sn-watcher as the culprit #116

Closed
areographe opened this issue Nov 15, 2020 · 5 comments

Comments

@areographe
Copy link

* Cinnamon version (cinnamon --version): 4.6.7 
* Nemo version (nemo --version): 4.6.5
 * Distribution - (Mint 17.2, Arch, Fedora 25, etc...): Manjaro Cinnamon 5.9.8-1
 * Graphics hardware *and* driver used:
Graphics:  Device-1: Intel Skylake GT2 [HD Graphics 520] vendor: Lenovo driver: i915 v: kernel 
           bus ID: 00:02.0 chip ID: 8086:1916 
           Display: x11 server: X.Org 1.20.9 compositor: muffin driver: intel 
           unloaded: modesetting alternate: fbdev,vesa display ID: :0 screens: 1 
           Screen-1: 0 s-res: 1920x1080 s-dpi: 96 s-size: 508x285mm (20.0x11.2") 
           s-diag: 582mm (22.9") 
           Monitor-1: eDP1 res: 1920x1080 hz: 60 dpi: 157 size: 310x170mm (12.2x6.7") 
           diag: 354mm (13.9") 
           OpenGL: renderer: Mesa Intel HD Graphics 520 (SKL GT2) v: 4.6 Mesa 20.2.2 
           direct render: Yes 

 * 32 or 64 bit: 64-bit

Hi! Just wanted to start by saying thank you all for making the best and most solid desktop environment and libraries I have used. This is the first major issue I have come across in over a year of using Cinnamon and Xapp, and while it's not urgent, I would love to find out what's going on and how to fix it.

As of a week ago, after logging in, the Cinnamon panel will load, along with the Calendar applet, a Bash Sensors applet, nm-applet and blueman. Then there is a pause of around 30-40 seconds, during which nothing visibly happens on screen. After the pause,

  1. The desktop background loads
  2. The 'system tray' panel applet loads
  3. The xdg-autostart / "Startup Applications" apps and daemons all start at once

Before this last week, this entire "logging-in and starting Cinnamon and autostart applications" process would take ~8 seconds, as opposed to ~45 seconds currently.

My .xsession-errors log has this message

LOG: [LookingGlass/info] Cinnamon took 630 ms
cinnamon-session[1043]: WARNING: t+32.78984s: Application 'xapp-sn-watcher.desktop' failed to register before timeout
Flag 0x0001, status 0, EXIT 1 STAT 0

It looks like there is some issue with xapp-sn-watcher that causes the 30-40 second delay. This has been happening to me for around 7-10 days, but I can't see any package upgrades related to cinnamon or Xapps during that period of time. However, I have upgraded, installed and removed multiple 'icon theme' packages in pacman over that period, while testing out new themes and icon styles. I have Googled the symptoms but have had no luck finding anyone else experiencing this same issue.

I created a new user account and tried logging in with it, and the same issue occurred, with the same error message (including 30+ second delay) in that user's .xsession-errors, so I don't think it's related to my .config folder.

I have a feeling this might not be reproducible for others, so is there any way I can run xapp-sn-watcher in 'verbose' mode or otherwise create a log of any errors it is experiencing? I am very curious about what might be causing this, although I don't have any C experience I have just finished uni for the year so happy to help debug in any way I can, I have lots of time! Thanks again.

@icarter09
Copy link
Member

Have you tried looking/asking on the Manjaro forums? Noticed you are using Manjaro so that might be a good place to ask if anyone there is using Cinnamon and has noticed the issue.

@areographe
Copy link
Author

Yes, I did post over there but I haven't had anyone say they've noticed the same issue, although my post has only been up for one day. Sorry if I've posted here and it's not relevant, I'm happy to close this issue if you all think it's something I probably need to talk to the Manjaro community about. I just want to mention that I tried temporarily removing the xapp-sn-watcher.desktop file from /etc/xdg/autostart/ and rebooted the computer with (so far) no visible issues - is it possible that my use case doesn't require this daemon to be running, for example if I use very few KDE- or Qt-related applications? If so, my problem is solved for now, but if this daemon is actually crucial for some part of Cinnamon or associated X-apps software I will look for a better solution. Thank you for your prompt response btw!

@icarter09
Copy link
Member

No problems and glad you found a work around for the time being. It's ok to post it here. Just wanted to also recommend the reaching out to the Manjaro community in case you hadn't already. Another good place to ask would be the Mint forums (in case you haven't already). I'm not that familiar with Manjaro Cinnamon, but will try to dig into the issue for you. Feel free to post your files from /home/<username>/.xsession-errors or /var/log/syslog.

@mtwebster
Copy link
Member

Hi what version of libxapp (or xapps - not sure on your distro) do you have?

We encountered this issue a while back but should be resolved in 1.8.9.

Have you tried looking at any autostart apps that have a tray icon (this is the xapp applet, not the 'systray' applet)? Perhaps you could try disabling them, see if the issue goes away, and then re-add them one-by-one to find a culprit.

@areographe
Copy link
Author

Mate I am so sorry about this hassle. I actually have just been combing through my recollections of any changes or tweaks I may have made to config files outside of my home directory and I remembered that I added GTK_USE_PORTAL=1 to my /etc/environment, which I think I added to force Qt-based applications to use more 'native' File Open and File Save dialogue boxes under Cinnamon on all user accounts? Either way I removed this variable and rebooted and the problem appears to be fixed. Not 100% sure but I think, as I kind of suspected, it was a change I had made without fully understanding its effects that was to blame after all.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

3 participants