Hibernation/Hibernate not functional on lxqt

[wretchedneo]

Is this a new report?

Yes

System Info

Void 6.13.12_1 x86_64 GenuineIntel notuptodate hold rFFFF

Package(s) Affected

liblxqt-2.2.0_2 lxqt-2.1.0_1

Does a report exist for this bug with the project's home (upstream) and/or another distro?

No response

Expected behaviour

The system should enter hibernation/suspend itself.

Actual behaviour

Nothing happens when invoked using lxqt-runner. when invoked using terminal: $ lxqt-leave --hibernate systemd: "CanHibernate" = "na" ** Dbus error ************************** Error name "org.freedesktop.DBus.Error.InvalidArgs" Error msg "No such interface “org.freedesktop.DBus.Properties”" dbusCall: QDBusInterface is invalid "org.freedesktop.ConsoleKit" "/org/freedesktop/ConsoleKit/Manager" "org.freedesktop.ConsoleKit.Manager" "CanHibernate"

Steps to reproduce

1. Trigger hibernate either from lxqt-runner or manually from the terminal with command lxqt-leave --hibernate

[grtcdr]

Disclaimer: I'm not a Void maintainer or LXQT developer though I'd like to ask you some questions because the issue lacks a bit of information that could help highlight the source of the problem.

I'm wondering to myself if D-Bus is just unavailable? Are you starting the graphical session with dbus-launch? If not, how are you starting it?

What's surprising is that LXQT wants to trigger session actions via consolekit instead of over the logind interface. Do you have elogind installed?

Related: https://github.com/void-linux/void-packages/issues/13326

[wretchedneo]

I'm wondering to myself if D-Bus is just unavailable? Are you starting the graphical session with dbus-launch? If not, how are you starting it?

I have dbus enabled as a service in runit, therefore it always runs in the background. This is my .xinitrc which i use to start the X session: exec pipewire & exec pipewire-pulse & xhost +SI:localuser:root & exec startlxqt

Do you have elogind installed?

$ xbps-query -s elogind
[*] elogind-252.9_2    Standalone logind fork
[*] libelogind-252.9_2 Standalone logind fork - elogind library

I have found a temporary solution to this, which is to replace $ lxqt-leave --hibernate with $ loginctl suspend suspend and hibernate works mostly the same, other than suspend puts the running system into ram, while hibernate puts it into the storage disk itself.

[grtcdr]

I have dbus enabled as a service in runit, therefore it always runs in the background.

You may very well have D-Bus running, but the system-provided dbus service is only running a system bus, you can verify this by checking the contents of the service file:

$ cat /etc/sv/dbus/run 
#!/bin/sh
exec 2>&1
[ ! -d /run/dbus ] && install -m755 -g 22 -o 22 -d /run/dbus
exec dbus-daemon --system --nofork --nopidfile

Notice how the dbus-daemon is started with the --system flag, that's essential but it's not enough for most graphical environments.

You also need to make sure you're running a user session, and that's something your display manager or your launch script is supposed to do.

I don't use LXQt but here's how I start the Sway compositor, it's just an example meant to illustrate how a D-Bus user session is instantiated:

dbus-launch --exit-with-session -- sway

Sidenote: reading through your xinitrc, I'm confused as to the correctness of the script. You seem to be chaining exec calls one after the other, and using the & to background the exec call, but then you continue to append more commands. I'm not sure how that is supposed to play out.

I'd probably rewrite the .xinitrc file as follows:

pipewire &
pipewire-pulse &
xhost +SI:localuser:root &
exec dbus-launch --exit-with-session -- startlxqt

With that, your user services are in the background and your dbus-enabled LXQt graphical session takes over the shell process that launched it.

I have found a temporary solution to this, which is to replace $ lxqt-leave --hibernate with $ loginctl suspend

Good, you can totally do that but if LXQt is configured to talk to ConsoleKit, it means you can't use the LXQt's own dialog to trigger session actions and that's a bummer.

[wretchedneo]

I'm confused as to the correctness of the script. You seem to be chaining exec calls one after the other, and using the & to background the exec call, but then you continue to append more commands.

My .xinitrc is mostly the same as what you wrote except the dbus part, I believe the formatting was wrong in github:

exec pipewire &
exec pipewire-pulse &
xhost +SI:localuser:root &
exec startlxqt

I will try the xinitrc suggested by you and will report back.

[wretchedneo]

With that, your user services are in the background and your dbus-enabled LXQt graphical session takes over the shell process that launched it.

I am still seeing the same error though I have these 2 new processes now:

[grtcdr]

I don't think the first process is new, that should be the one spawned by the /etc/sv/dbus service.

I am still seeing the same error

At least we know it's not a setup issue now. It's either a misconfiguration in one of Void's templates or a bug in LXQt. I can't comment on which is more plausible, I've only skimmed the templates and the build systems of LXQt.

Can someone else chime in here with some insights as to why LXQt is looking for consolekit instead of communicating over elogind's interfaces?

[grtcdr]

I do need to ask though, how are you starting elogind?

One may tempted to activate the /etc/sv/elogind service (at least I was), but you never have to do that (and things happen to break if that service is manually enabled). If you have a symlink named elogind under your /var/service directory, you should remove that right away (a reboot may be necessary).

[wretchedneo]

I do need to ask though, how are you starting elogind?

I don't actually know, I neither have it as a service in runit, nor am I spawning it explicitly by some init/bash script. It just automatically spawns whenever I start up my system. The Process name is "elogind-daemon"

One may tempted to activate the /etc/sv/elogind service (at least I was), but you never have to do that (and things happen to break if that service is manually enabled). If you have a symlink named elogind under your /var/service directory, you should remove that right away (a reboot may be necessary).

Yes I am not doing that, I only have udevd, dbus, & acpid running as services which are actually related to the system.

[grtcdr]

It just automatically spawns whenever I start up my system. The Process name is "elogind-daemon"

D-Bus is starting it.

Yes I am not doing that, I only have udevd, dbus, & acpid running as services which are actually related to the system.

Okay, your setup seems well-configured, better bring this up with the LXQt folks, you may also consider linking the tickets to one another that way we can track both conversations.

[wretchedneo]

https://github.com/lxqt/lxqt/issues/2732

I tried it, but they told me to come here. I will try to open another issue.

[grtcdr]

I don't recommend opening a new ticket, they'd likely file it as a duplicate (seeing as it is), just have them know that LXQt is attempting to send session commands over consolekit's D-Bus interface when it really shouldn't. This could be a packaging issue, but to my (inexperienced) eyes, it doesn't seem that way.

By the way, the current version discrepancy could be the issue, but the only way around that is for Void Linux to update the lxqt package, you may have a go at it yourself if you feel confident upgrading the versions and contributing back to the project. Otherwise, we'll just have to patiently wait as the packages get updated to their latest versions.

[wretchedneo]

I don't recommend opening a new ticket, they'd likely file it as a duplicate (seeing as it is), just have them know that LXQt is attempting to send session commands over consolekit's D-Bus interface when it really shouldn't.

Yes I will follow your advice on this, thanks so much for staying up on this issue :]

This could be a packaging issue, but to my (inexperienced) eyes, it doesn't seem that way.

I also think the same, aswell as the lxqt mainitainers- I believe that is why they told me to report this issue to void. but I am just as or more inexperienced than you.

but the only way around that is for Void Linux to update the lxqt package, you may have a go at it yourself if you feel confident upgrading the versions and contributing back to the project. Otherwise, we'll just have to patiently wait as the packages get updated to their latest versions.

I will look into trying this and will report back if I manage to find something that could help!

[grtcdr]

Yes I will follow your advice on this, thanks so much for staying up on this issue :]

You're welcome, I wish I could have been of more help. I hope you find your answers.

I will look into trying this and will report back if I manage to find something that could help!

I'd probably ask around IRC (#voidlinux) if there exists any blocker for lxqt being set to 2.2.0, most (if not all) other packages are set to 2.2.0. It would be interesting to here directly from someone with more knowledge on the topic.

[wretchedneo]

I'd probably ask around IRC (#voidlinux) if there exists any blocker for lxqt being set to 2.2.0, most (if not all) other packages are set to 2.2.0. It would be interesting to here directly from someone with more knowledge on the topic.

I will ask there also.

I want to ask something, why did you advice against enabling elogind as a service and instead only enable dbus. this suggests that elogind should be enabled as a service if one is having issues with suspend or hibernate.

Also in the same wiki- under 'startx dbus integration' the de/wm is started using dbus-run-session instead of dbus-launch --exit-with-session what is the difference between these two?

[grtcdr]

I want to ask something, why did you advice against enabling elogind as a service and instead only enable dbus. this suggests that elogind should be enabled as a service if one is having issues with suspend or hibernate.

My reasons were based on my own experience using elogind. My computer was all kinds of broken when I enabled that service manually. I advised you against activating it manually because Void Linux should configure elogind such that D-Bus launches it properly for you without any manual intervention on your part. D-Bus is super malleable and distributions are free to configure services as they see fit so it makes sense for Gentoo to say something while Void says another:

To make use of its features, install the elogind package and make sure the system D-Bus is enabled. You might need to log out and in again.

Void only mentions enabling the service when one is having trouble (it doesn't exactly say what sort of trouble warrants a manual activation, so... I don't know):

If you're having any issues with elogind, enable its service, as waiting for a D-Bus activation can lead to issues.

---

Also in the same wiki- under 'startx dbus integration' the de/wm is started using dbus-run-session instead of dbus-launch --exit-with-session what is the difference between these two?

dbus-launch --exit-with-session and dbus-run-session are equivalent, both start a session bus and exit when the specified command exits. They don't support the same set of arguments but they do have this usecase in common.

[wretchedneo]

I advised you against activating it manually because Void Linux should configure elogind such that D-Bus launches it properly for you without any manual intervention on your part.

Indeed you were right, when I tried to activate elogind as a service, lots of output came on my console telling me that "elogind is already running at pid 11xx" so dbus starts it by itself.

Void only mentions enabling the service when one is having trouble (it doesn't exactly say what sort of trouble warrants a manual activation, so... I don't know):

Activating elogind as a service only outputs lots of "already running" errors- I do not think it will fix this problem then..

dbus-launch --exit-with-session and dbus-run-session are equivalent, both start a session bus and exit when the specified command exits. They don't support the same set of arguments but they do have this usecase in common.

Understood. the man page of these commands also mention similar traits- but I didn't get it earlier I believe using dbus-launch --exit-with-session is more appropriate for the graphical X session as the man page explicitly gives examples for such usecases only.

[grtcdr]

Understood. the man page of these commands also mention similar traits- but I didn't get it earlier I believe using dbus-launch --exit-with-session is more appropriate for the graphical X session as the man page explicitly gives examples for such usecases only.

I have used both dbus-launch --exit-with-session and dbus-run-session to launch Sway and Labwc (both of which are supported compositors by LXQt). I haven't noticed any difference between the two. I'm currently using the former, though.

[bugcrazy]

Disclaimer: I'm not a Void maintainer or LXQT developer though I'd like to ask you some questions because the issue lacks a bit of information that could help highlight the source of the problem.

I'm wondering to myself if D-Bus is just unavailable? Are you starting the graphical session with dbus-launch? If not, how are you starting it?

What's surprising is that LXQT wants to trigger session actions via consolekit instead of over the logind interface. Do you have elogind installed?

Related: #13326

Consolekit installed alone does not work with hibernation, you need the nologind package to enable hibernation.

Check out my tutorial on consolekit and nologind template:

https://notabug.org/Marcoapc/voidpkgs/wiki/ConsoleKit2+replace+Elogind

https://notabug.org/Marcoapc/voidpkgs/src/master/srcpkgs/nologind

[classabbyamp]

consolekit is not a supported configuration on void, you'll be on your own if you use it

[bugcrazy]

consolekit is not a supported configuration on void, you'll be on your own if you use it

Yes, I agree, regarding the ticket problem, it has to do with how elogind interacts with d-bus, in nologind I can have hibernation with functions in d-bus, perhaps by analyzing nologind, I will find a solution to the problem with elogind.

https://github.com/rodlie/nologind

[grtcdr]

Relevant pull request that may resolve this specific issue: https://github.com/void-linux/void-packages/pull/55900

[wretchedneo]

Relevant pull request that may resolve this specific issue: #55900

I haven't tried the Wayland session yet, will give this a try today

[grtcdr]

That alone may not be enough, the lxqt package will also need to be bumped.

[axtloss]

Relevant pull request that may resolve this specific issue: #55900

I doubt that it would, lxqt-wayland-session only adds files specific to the lxqt wayland session, wretchedneo is using xorg though, so it shouldn't have any effect on their issue

[wretchedneo]

something similar has lately started happening with lxqt-runner $ lxqt-runner QCssParser::parseColorValue: Specified color with alpha value but no alpha given: 'rgba 20, 20, 20' systemd: "CanHibernate" = "na" ** Dbus error ************************** Error name "org.freedesktop.DBus.Error.InvalidArgs" Error msg "No such interface “org.freedesktop.DBus.Properties”" dbusCall: QDBusInterface is invalid "org.freedesktop.ConsoleKit" "/org/freedesktop/ConsoleKit/Manager" "org.freedesktop.ConsoleKit.Manager" "CanHibernate" systemd: "CanSuspend" = "yes"

[wretchedneo]

The issue is fixed. The problem was I hadn't setup a swap partition, and hibernation needed exactly that I don't use hibernation as much as I use suspend- hence I do not know how to get it working perfectly I only went as far as being able to execute "lxqt-leave --hibernate" and "loginctl hibernate" successfully. As this issue was originally about not being able to do so.

Here are the thngs I did:

• make a swap partition usually of about 3-5gb.
• mount it using swapon
• generate a new fstab # xgenfstab -U / > /etc/fstab
• install package runit-swap from the official repos
• enable runit-swap as a service # ln -sf /etc/sv/runit-swap /var/service/
• reboot and try $ loginctl hibernate or $ lxqt-leave --hibernate