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.
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???
$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.
thats cool - had to wait until my installation is finished, damn HDs - i might have a idea
Edit: It rings a bell
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.
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.
And sorry Walter…yours was a worthy post, but I gotta go with Alf on the bell-ringing meme contest!
Yes, I remember
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.
erm - no - happend in Arch too
Also it does not happen on Debian derivatives, per se. No problem with Lubuntu or Siduction.
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 but with openbox dont notice the delay…
@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
Next blocker found - it is the Logitech Cam - if connected to usb it causes a huge delay.
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
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.
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.
i turn coredump on from time to time - never see a qlipper crash. Please file a bug in qlipper - @palinek has push access.
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
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.