LXQt panel appearing with huge delay when home directory moved

(Alf Gaida) #41

tried yesterday - no improvement. And as i said - i use debian packages in siduction - so … - of course, if the patch would improve something i would port it back to the upcoming stable. But the patch don’t change a symbol, so it should be effective without recompiling anything.

(Walter Lapchynski) #42

After a couple reboots (this is VBox, btw) it seems that now the issue is that I get 20 seconds of black screen before the desktop comes up and then there’s just a second or two of delay before the panel is up. So maybe it’s not the panel at all???

Looking at $HOME/.config/lxqt/debug.log, here’s results from xfwm4 and openbox respectively:

2019-05-07 17:17:16.095 (0x7fffdc38b550) Debug: New PolkitAgentListener  0x5578cfce1560
2019-05-07 17:17:16.192 (0x7fffdc38b550) Debug: Adding new listener  PolkitQt1::Agent::Listener(0x7fffdc38b560) for  0x5578cfce1560
2019-05-07 17:17:30.465 (0x7ffd49605980) Debug: systemd: "CanHibernate" = "yes"
2019-05-07 17:17:32.690 (0x7ffd49605980) Debug: systemd: "CanSuspend" = "yes"
2019-05-07 17:17:33.732 (0x7ffcea9e0eb0) Debug: systemd: "CanReboot" = "yes"
2019-05-07 17:17:34.838 (0x7ffcea9e0eb0) Debug: systemd: "CanPowerOff" = "yes"
2019-05-07 17:17:37.829 (0x7fff8df4d440) Debug: ()
2019-05-07 17:17:39.905 (0x7fff8df4d440) Debug: WinIdChange 1000008 handle QWidgetWindow(0x560962319950, name="LXQtPanel panel1Window") QScreen(0x560961fb0ca0, name="Virtual1")
2019-05-07 17:17:43.020 (0x7fff8df4d440) Debug: Systray started
2019-05-07 17:17:46.233 (0x7fff99c17200) Debug: Starting idlenesswatcher
2019-05-07 17:24:07.283 (0x7ffcf58165e0) Debug: New PolkitAgentListener  0x55f2dea25280
2019-05-07 17:24:07.338 (0x7ffcf58165e0) Debug: Adding new listener  PolkitQt1::Agent::Listener(0x7ffcf58165f0) for  0x55f2dea25280
2019-05-07 17:24:18.881 (0x7ffc23655440) Debug: systemd: "CanHibernate" = "yes"
2019-05-07 17:24:20.459 (0x7ffc23655440) Debug: systemd: "CanSuspend" = "yes"
2019-05-07 17:24:21.795 (0x7ffc21fe90d0) Debug: systemd: "CanReboot" = "yes"
2019-05-07 17:24:22.965 (0x7ffc21fe90d0) Debug: systemd: "CanPowerOff" = "yes"
2019-05-07 17:24:24.785 (0x7ffe98458a30) Debug: ()
2019-05-07 17:24:26.446 (0x7ffe98458a30) Debug: WinIdChange 1000008 handle QWidgetWindow(0x559a0dbb1d30, name="LXQtPanel panel1Window") QScreen(0x559a0d8beca0, name="Virtual1")
2019-05-07 17:24:26.596 (0x7ffe98458a30) Debug: Systray started
2019-05-07 17:24:31.282 (0x7ffeacd334f0) Debug: Starting idlenesswatcher

Both of those were started roughly at the beginning of the minute, so openbox took less time to load over all, but still 30 seconds. Every step seems a little slower in xfwm4 but the glaring problem is the first line. Double the amount of time to get the polkit running.

(Alf Gaida) #43

thats cool - had to wait until my installation is finished, damn HDs - i might have a idea

Edit: It rings a bell :smiley:

(Walter Lapchynski) #44

(Alf Gaida) #45

(Alf Gaida) #46

Ok, found it - i recommend preload - and it is right now not in debian/testing, someone forget to write an unblock request. Preload solve nothing, but migitate the problem so it is not that visible anymore. @tsujan - we talked a while ago about it, it just tracks the needed things and preload them so they are already in memory when needed - speed up some things dramatically.

Neverless, we should fix the blocking behaviour in the panel.

(Jim Shriner) #47

Alf, your comment about Siduction and the custom Siduction kernels made me remember an issue I experienced with Sparky LXQt that may be of assistance here.

Not sure if it’s related to this discussion, but it sure sounds like it. And if so, perhaps I can shave many man-hours from your troubleshooting. Long story short…I was experiencing unbearable delays with the LXQt desktop loading in Sparky. But Siduction was a dream. They were both Debian-based and both using the same version of LXQt. But they were also using different desktop/login managers, different window managers, and different kernels.

Using systemd-analyze-blame, I swapped out login managers and window managers and re-ran systemd-analyze-blame to see what effect that action had on the boot process. Troubleshooting lead me to the xfwm4 issue and resolution with exim4, but no satisfaction. Ultimately, and quite by chance perhaps, I was lead to the kernel. Siduction provides its own custom kernel by default, while Sparky uses a Debian kernel by default; but has a custom kernel available. Switching to Sparky’s custom kernel resolved everything, and I haven’t had a problem since.

A forum discussion with fellow linux-users on “Bruno’s All Things Linux” (BATL) forum was somewhat helpful to me in this process. No devs with skills, just linux junkies like me swapping ideas. An overview can be viewed from this link:

With my post at #60 summarizing the solution for me and others. Of course, the caveat is that we were all experiencing this issue in Virtualbox, not bare metal. I mention it here because your comment regarding the Siduction kernel made me remember this long-forgotten resolution. But perhaps you’re onto the solution without realizing it?

I only hope I’m not wasting your valuable time by pointing you to a Virtualbox issue that has no bearing on the current bare metal issue.

(Jim Shriner) #48

And sorry Walter…yours was a worthy post, but I gotta go with Alf on the bell-ringing meme contest! :stuck_out_tongue_winking_eye:

(Pedram Pourang) #49

Yes, I remember preload.

The whole thing is so strange:

  • Apparently, it only happens on Debian and its derivatives.
  • It disappears for some by changing WM (me) or even Kernel (@hedon’s comment).
  • It’s always related to Status Notifier and login. It doesn’t happen when Panel is started after login.

(Alf Gaida) #50

erm - no - happend in Arch too

(Walter Lapchynski) #51

Also it does not happen on Debian derivatives, per se. No problem with Lubuntu or Siduction.

(Ringo32) #52

with xfwm4 / kwin i notice some delay if its side by side systray and statusnotif… but have now a spacer inbetween but i didnt watched the delay :stuck_out_tongue: but with openbox dont notice the delay…

(Alf Gaida) #53

@wxl - the panel is a bit slower initialized as in openbox, one major difference is that we have preload installed - and maybe irqbalance make a difference too

(Alf Gaida) #54

Next blocker found - it is the Logitech Cam - if connected to usb it causes a huge delay.


(Alf Gaida) #55

It has now - don’t really know if it fixes the behaviour, but in both openbox and xfwm4 the panel appears after 4s with plugged in camera - dunno if the patch does it, but hey :blush:

(Pedram Pourang) #56


However, we can’t be sure of anything unless:

(1) Either the cause is found somewhere in the code and fixed; or

(2) It doesn’t happen anymore.

(Pedram Pourang) #57


This is VERY unrelated but I should tell you:

When you don’t install systemd-coredump, you won’t know qlipper crashes on exit almost always. That’s why I don’t use qlipper – have never found time to find the cause.

(Alf Gaida) #58

i turn coredump on from time to time - never see a qlipper crash. Please file a bug in qlipper - @palinek has push access.

(palinek) #59

This is not qlipper fault, but the (sub)process handling of lxqt/libqtxdg. We have been discussing it previously -> https://github.com/pvanek/qlipper/issues/34#issuecomment-248535444

(Pedram Pourang) #60

Tonight, I encountered the opposite “problem” for the first time in years: lxqt-panel started so quickly that it was running before KWin’s compositor (no blurring). I logged out and in to test; it started fast but, fortunately, after KWin.

Not a real problem because if it happens again, I’ll put in inside a startup script.