[SOLVED] Bug with elogind-255.4-r2

...

Originally Posted by ZhaoLin1457 Both packages compile perfectly in a complete and updated installation of Slackware-current. Please don't blame Slackware for the problems caused by the fact that you are using a partial installation.

I found them both, and I won't blame slackware. I'll just swallow hard and install kde next time. Just because I install it doesn't mean I have to use it, does it? I should be able to fix that. And if Wayland boots instead of Xorg, I'll be dragged a bit further into the 21st century

In my defence, I opted for networkmanager on these installs. But my 'official' vpn package requires Systemd . So I gladly went back to rc scripts.

Originally Posted by ZhaoLin1457 I think there are other programs or services that need to be informed about the wake up. So we would need a broadcast call. For example, pages opened by Firefox or Thunderbird will behave strangely, even if NetworkManager is restarted.

At least here it solves all problems, as the only problem was NM

NetworkManager is not "restarted" by the hook.sh, so Firefox and Thunderbird, etc .. behave perfectly.

As far as I tested : this workaround is perfect.

Originally Posted by H1p8r10n At least here it solves all problems, as the only problem was NM NetworkManager is not "restarted" by the hook.sh, so Firefox and Thunderbird, etc .. behave perfectly. As far as I tested : this workaround is perfect.

I will test your solution tonight. I'm sorry, but now it's 7:30 pm for me and I have other things to do.

Originally Posted by ZhaoLin1457 I will test your solution tonight. I'm sorry, but now it's 7:30 pm for me and I have other things to do.

Yes, cool

The hook.sh basically sends a wake up dbus signal to NM, so what it does is just exactly what elogind should do.

Originally Posted by H1p8r10n The hook.sh basically sends a wake up dbus signal to NM, so what it does is just exactly what elogind should do.

No, elogind does something different. He announces to anything interested (signal broadcast) that it is time to wake up. Including here the NetworkManager.

~ dbus-monitor --system "type='signal',sender='org.freedesktop.login1',interface='org.freedesktop.login1.Manager'"
... removed some noise messages ...
signal time=1713350818.151513 sender=:1.1 -> destination=(null destination) serial=340 path=/org/freedesktop/login1; interface=org.freedesktop.login1.Manager; member=PrepareForSleep
   boolean false

https://github.com/elogind/elogind/i...ent-2060986639

Here's what happens for me when trying the hook.sh script and elogind-255.4_r2 when suspending with Thunderbird running:
- NM reconnects to the wlan network
- Thunderbird seems to be alive, I can read old mails, but connection to server is down - can't get new mails or move mails to trash.

So it's about more than just waking up NM.

See crtlaltca's post at github.com/elogind:
https://github.com/elogind/elogind/i...ent-2060986639

@business_kid:

Did you try downgrading polkit to v123 (from slackware.uk/cumulative)?

For me, the shutdown menu and the powermanager settings disappear with elogind-252.23 and polkit-124 from the -current repo. But if I downgrade to polkit-123, everything's OK. Also with a polkit-124 rebuilt against elogind-252.23.

Originally Posted by kgha @business_kid: Did you try downgrading polkit to v123 (from slackware.uk/cumulative)?

I was on polkit-123, iirc. It wasn't from cumulative, but from Current of 2024-03-30. I only grabbed the polkit-124 package today. Screen saver is still misbehaving, as is suspend/poweroff in Mate. Anyhow, I'm not particularly inconvenienced by this, as I can get back to sddm, and shut down/reboot from there. It's not a laptop, so suspend & hibernate are moot points.

It's funny what you notice. I haven't compiled in a while, and noticed libdirs seem to be defaulting to /lib64 & /usr/lib64. Have people copped on to the wisdom of that idea?

EDIT: Another install from scratch is on the way, as this system is not kosher enough. I'm just waiting for these issues to go quiet. I'll install the iso, install mate as well, edit rc.4 to make sure kde doesn't show except as an absolute last resort .

Originally Posted by kgha Here's what happens for me when trying the hook.sh script and elogind-255.4_r2 when suspending with Thunderbird running: - NM reconnects to the wlan network - Thunderbird seems to be alive, I can read old mails, but connection to server is down - can't get new mails or move mails to trash. So it's about more than just waking up NM. See crtlaltca's post at github.com/elogind: https://github.com/elogind/elogind/i...ent-2060986639

And that's why I called it "workaround" , not "fix"

Originally Posted by H1p8r10n And that's why I called it "workaround" , not "fix"

How about to make dbus-send to send something like elogind do?

I talk about something like sending a DBUS signal with "destination=(null destination) path=/org/freedesktop/login1; interface=org.freedesktop.login1.Manager; member=PrepareForSleep boolean false"

Originally Posted by H1p8r10n And that's why I called it "workaround" , not "fix"

You even called it a perfect workaround that solves all problems

Originally Posted by LuckyCyborg How about to make dbus-send to send something like elogind do? I talk about something like sending a DBUS signal with "destination=(null destination) path=/org/freedesktop/login1; interface=org.freedesktop.login1.Manager; member=PrepareForSleep boolean false"

As I understand it, that's exactly what the elogind people are working at.

Originally Posted by kgha As I understand it, that's exactly what the elogind people are working at.

Yup. You are right. That's exactly what the elogind people tries to teach elogind to do. Of course, in C/C++ as usual.

BUT, as @H1p8r10n demonstrated, we can send DBUS commands also from an elogind hook made in Bash, also at appropriate times.

So, why not to try to send exactly that missing DBUS signal via an elogind hook like this?

IF we manage to properly "fix" elogind 255.4-rX by using a hook, this will be also a nice proof that indeed the fix will be elogind sending that DBUS signal at appropriate times.

Originally Posted by LuckyCyborg Yup. You are right. That's exactly what the elogind people tries to teach elogind to do. Of course, in C/C++ as usual. BUT, as @H1p8r10n demonstrated, we can send DBUS commands also from an elogind hook made in Bash, also at appropriate times. So, why not to try to send exactly that missing DBUS signal via an elogind hook like this? IF we manage to properly "fix" elogind 255.4-rX by using a hook, this will be also a nice proof that indeed the fix will be elogind sending that DBUS signal at appropriate times.

Brilliant suggestion. Unfortunately I haven't the necessary knowledge. Do you?

Originally Posted by kgha Brilliant suggestion. Unfortunately I haven't the necessary knowledge. Do you?

I (will) do some experiments in that sense and I will share the results when I will get something consistent.

Unfortunately, right now I have one single computer sporting Slackware-current and (right) now it chews on a new build of Plasma6.

In fact, this HP Elite 8300 USDT (a mini-PC) is the single computer box which I have at disposition right now, excluding my old friend Core2 Duo laptop, because I am far away from home since the last Summer. Well, nothing special, just a (really) prolonged job trip for a geologist.