[SOLVED] Bug with elogind-255.4-r2

rizitis · 04-19-2024, 04:01 PM

I know that PAT rebuilded elogind etc...
JFI, if i suspend from cli

Code:

echo mem > /sys/power/state

everything works fine...
And only if i suspend from graphical interface I have the bug.

The only different is than when I resume from suspend from cli I dont have to re-login and user session appears BUT when I resume from suspend from graphical I need to re-loging and the bug is here, also this mean new session.

Since it happens in GNOME,XFCE and KDE its not from there the reason.
I use GDM display manager , you dont, so its not display manager also.

Suspend from cli its a low_level suspend, but from gui is something different. Bug exist when authentication needed by gui to resume from suspend. (keeping that for now).

I make a sysv script so it can run during suspend and monitoring dbus

Code:

#!/bin/bash


DBUS_MONITOR="/usr/bin/dbus-monitor"

monitor_dbus() {
    $DBUS_MONITOR --system "type='signal',interface='org.freedesktop.login1.Manager'" "type='signal',interface='org.freedesktop.NetworkManager'" > /tmp/dbus_monitor.log &
}

case "$1" in
    start)
        echo "Starting system monitoring..."
        monitor_dbus
        ;;
    stop)
        echo "Stopping system monitoring..."
        ;;
    restart)
        echo "Restarting system monitoring..."
        $0 stop
        sleep 1
        $0 start
        ;;
    *)
        echo "Usage: $0 {start|stop|restart}"
        exit 1
        ;;
esac

exit 0

after reboot... for network back, examine the output and show some issues but its not clear why and for what reason happens.
One message was very intresting:

Code:

signal time=1713549936.701372 sender=:1.2 -> destination=(null destination) serial=1162 path=/org/freedesktop/NetworkManager; interface=org.freedesktop.NetworkManager; member=DeviceRemoved

DeviceRemoved signal from org.freedesktop.NetworkManager, indicates the removal of a device, possibly related to the system reboot or shutdown BUT possible not!

So I create a script:

Code:

#!/bin/bash


output_file="suspend_output.txt"


print_separator() {
    echo "----------------------------------------" >> $output_file
}


execute_command() {
    echo "Executing command: $1" >> $output_file
    echo "Output of command: $1" >> $output_file
    eval $1 >> $output_file
    print_separator
}


echo "NetworkManager status before suspend:" >> $output_file
execute_command "ps aux | grep NetworkManager"


echo "Network device status before suspend:" >> $output_file
execute_command "nmcli device status"


echo "Active connections before suspend:" >> $output_file
execute_command "nmcli connection show --active"

echo "iwconfig;ifconfig;ip link show" >> $output_file
execute_command "iwconfig;ifconfig;ip link show"

# Suspend the laptop
echo "Suspending the laptop..."

echo "Suspending the laptop..." >> $output_file
# echo mem > /sys/power/state # for cli suspend 
sleep 10
wait
print_separator() {
    echo "----------------------------------------" >> $output_file
}

echo "" >> $output_file
echo "NetworkManager status after resume:" >> $output_file
execute_command "ps aux | grep NetworkManager"


echo "Network device status after resume:" >> $output_file
execute_command "nmcli device status"


echo "Active connections after resume:" >> $output_file
execute_command "nmcli connection show --active"

echo "iwconfig;ifconfig;ip link show" >> $output_file
execute_command "iwconfig;ifconfig;ip link show"

The output edited for better compare is this:

Code:

NetworkManager status before suspend:
Executing command: ps aux | grep NetworkManager
Output of command: ps aux | grep NetworkManager
root      1387  0.0  0.0 367216 16432 ?        Ssl  22:39   0:00 /usr/sbin/NetworkManager
root      5876  0.0  0.0   4124  2212 pts/1    S+   22:50   0:00 grep NetworkManager

NetworkManager status after resume:
Executing command: ps aux | grep NetworkManager
Output of command: ps aux | grep NetworkManager
root      1387  0.0  0.0 367216 16432 ?        Ssl  22:39   0:00 /usr/sbin/NetworkManager
root      6026  0.0  0.0   4124  2216 pts/1    S+   22:50   0:00 grep NetworkManager
----------------------------------------
Network device status before suspend:
Executing command: nmcli device status
Output of command: nmcli device status
DEVICE             TYPE      STATE                   CONNECTION     
wlan0              wifi      connected               COSMOTE-769552 
lo                 loopback  connected (externally)  lo             
virbr0             bridge    connected (externally)  virbr0         
C4:DF:39:BA:BD:3C  bt        disconnected            --             
p2p-dev-wlan0      wifi-p2p  disconnected            --             
eth0               ethernet  unavailable             --             

Network device status after resume:
Executing command: nmcli device status
Output of command: nmcli device status
DEVICE             TYPE      STATE                   CONNECTION 
lo                 loopback  connected (externally)  lo         
virbr0             bridge    connected (externally)  virbr0     
C4:DF:39:BA:BD:3C  bt        unmanaged               --         
eth0               ethernet  unmanaged               --         
wlan0              wifi      unmanaged               --         
p2p-dev-wlan0      wifi-p2p  unmanaged               --         
----------------------------------------

Active connections before suspend:
Executing command: nmcli connection show --active
Output of command: nmcli connection show --active
NAME            UUID                                  TYPE      DEVICE 
COSMOTE-769552  03012060-8f5f-4db7-a88c-0e5d25958f87  wifi      wlan0  
lo              e3124feb-9263-41f1-b36a-399e62a942a7  loopback  lo     
virbr0          6d5a22ec-604e-4e1f-9ef5-b3b2359489e6  bridge    virbr0 

Active connections after resume:
Executing command: nmcli connection show --active
Output of command: nmcli connection show --active
NAME    UUID                                  TYPE      DEVICE 
lo      e3124feb-9263-41f1-b36a-399e62a942a7  loopback  lo     
virbr0  6d5a22ec-604e-4e1f-9ef5-b3b2359489e6  bridge    virbr0 

----------------------------------------
BEFORE:
iwconfig;ifconfig;ip link show
Executing command: iwconfig;ifconfig;ip link show
Output of command: iwconfig;ifconfig;ip link show
wlan0     IEEE 802.11  ESSID:"COSMOTE-769552"  
          Mode:Managed  Frequency:2.412 GHz  Access Point: 58:76:AC:E1:B6:81   
          Bit Rate=573.5 Mb/s   Tx-Power=3 dBm   
          Retry short limit:7   RTS thr:off   Fragment thr:off
          Encryption key:off
          Power Management:on
          Link Quality=60/70  Signal level=-50 dBm  
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:0   Missed beacon:0
          
AFTER:
iwconfig;ifconfig;ip link show
Executing command: iwconfig;ifconfig;ip link show
Output of command: iwconfig;ifconfig;ip link show
wlan0     IEEE 802.11  ESSID:off/any  
          Mode:Managed  Access Point: Not-Associated   Tx-Power=3 dBm   
          Retry short limit:7   RTS thr:off   Fragment thr:off
          Encryption key:off
          Power Management:on
----------------------------------------
BEFORE:
eth0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        ether 5c:60:ba:be:90:5e  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        
AFTER:
NOT EXIST!!! 
----------------------------------------
BEFORE:
lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 57  bytes 5856 (5.7 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 57  bytes 5856 (5.7 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        
AFTER:
lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 241  bytes 21068 (20.5 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 241  bytes 21068 (20.5 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
----------------------------------------
BEFORE:
virbr0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        inet 192.168.122.1  netmask 255.255.255.0  broadcast 192.168.122.255
        ether 52:54:00:3a:ad:45  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        
AFTER:
virbr0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        inet 192.168.122.1  netmask 255.255.255.0  broadcast 192.168.122.255
        ether 52:54:00:3a:ad:45  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
----------------------------------------
BEFORE:
wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.1.181  netmask 255.255.255.0  broadcast 192.168.1.255
        inet6 2a02:587:c406:5200:6ba:3c8d:6453:ae47  prefixlen 64  scopeid 0x0<global>
        inet6 fe80::375e:a8a0:b551:2965  prefixlen 64  scopeid 0x20<link>
        ether 34:6f:24:c7:94:03  txqueuelen 1000  (Ethernet)
        RX packets 2653  bytes 981239 (958.2 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 1468  bytes 336960 (329.0 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        
AFTER:
wlan0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        ether 34:6f:24:c7:94:03  txqueuelen 1000  (Ethernet)
        RX packets 2664  bytes 982525 (959.4 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 1470  bytes 337144 (329.2 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
----------------------------------------

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN mode DEFAULT group default qlen 1000
    link/ether 5c:60:ba:be:90:5e brd ff:ff:ff:ff:ff:ff
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DORMANT group default qlen 1000
    link/ether 34:6f:24:c7:94:03 brd ff:ff:ff:ff:ff:ff
4: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default qlen 1000
    link/ether 52:54:00:3a:ad:45 brd ff:ff:ff:ff:ff:ff
    
AFTER:
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast state DOWN mode DEFAULT group default qlen 1000
    link/ether 5c:60:ba:be:90:5e brd ff:ff:ff:ff:ff:ff
3: wlan0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default qlen 1000
    link/ether 34:6f:24:c7:94:03 brd ff:ff:ff:ff:ff:ff
4: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default qlen 1000
    link/ether 52:54:00:3a:ad:45 brd ff:ff:ff:ff:ff:ff
----------------------------------------

The removed device is eth0. And wifi is dead also after suspend from graphical interface...

Trying to put all of them in line, I think its udev problem during authentication and new session. (?)

LuckyCyborg · 04-20-2024, 02:44 AM

Quote:

Originally Posted by kgha

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

Quote:

Originally Posted by LuckyCyborg

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

Unfortunately, looks like the DBUS daemon does not accept signals sent on a path of an already registered DBUS service - i.e. on behalf of elogind. Probably for security reasons.

I have tried (without success) to use the command bellow:

Code:

dbus-send --system --type=signal \
  '/org/freedesktop/login1' \
  org.freedesktop.login1.Manager.PrepareForSleep boolean:false

LuckyCyborg · 04-20-2024, 02:53 AM

BTW, I believe that marking this thread as [SOLVED] is utterly wrong. NOPE, the issues on elogind 255.4 was NOT solved yet.

If we declare the latest development of elogind as being fundamentally incompatible with Slackware and the "solution" is to roll back, this also means throwing the towel.

As well we can switch to systemd and call a day, IF is too much for us the niche software like elogind made for 1% users niche Linux distributions - and this altogether.

Yeah, today is much simpler to use systemd as everyone else and people to have out of box a shinny Suspend/Resume on their S0ix driven laptops.

business_kid · 04-20-2024, 03:19 AM

Personally, I think the elogind maintainer sees this as a bug in his program. So if it's not fixed yet, we wait. You don't adopt systemd, hang your heads in shame, and go home.

Even if it means resurrecting pm-suspend & pm-hibernate I'm sure it can be done.

LuckyCyborg · 04-20-2024, 03:22 AM

Quote:

Originally Posted by business_kid

Personally, I think the elogind maintainer sees this as a bug in his program. So if it's not fixed yet, we wait. You don't adopt systemd, hang your heads in shame, and go home.

Even if it means resurrecting pm-suspend & pm-hibernate I'm sure it can be done.

My comment was literally regarding the marking of this thread as [SOLVED] when nothing was solved YET.

business_kid · 04-20-2024, 06:49 AM

Yes. But threads I post always seem to take off after I mark them solved

.

Anyhow, This laptop I'm on here is on ~Current of 2023-12-26, using polkit-123 & elogind-252.9 with xfce and all is well in the world of turning off options. I have to fiddle sound, because it defaults to <default> which is blank. That's annoying but I;m otherwise fine.

z80 · 04-20-2024, 07:08 AM

Quote:

Originally Posted by LuckyCyborg

BTW, I believe that marking this thread as [SOLVED] is utterly wrong. NOPE, the issues on elogind 255.4 was NOT solved yet.

Yes, the bug in elogind is not fixed but Slackware is working again (for me).

business_kid · 04-20-2024, 08:02 AM

Quote:

Originally Posted by z80

Yes, the bug in elogind is not fixed but Slackware is working again (for me).

Well, the OP (=you) can mark this thread as 'unsolved' or 'not solved' above the most recent post

business_kid · 04-20-2024, 02:27 PM

Actually, I've gone with a clean disk install here and I seem to be good here too, as regards a lot of stuff. I've just one MAJOR problem: I can only get kde!

It's the usual disaster, and I'll tackle it tomorrow. But to be fair, kde looks less gruesome than last time I was unavoidably landed in it.

One other thing: I seem to be missing that red mouse pointer.....I can only find black or white.

rizitis · 04-20-2024, 04:15 PM

Just some thoughts,

Bug appears only if resume by new session. Elogind updates from one version to other are huge... decades thousands lines.
Something very suspicius for bug is the switch from simple PIDs to PidRef structures.

Explain:
Session Leader Changes:
The switch from simple PIDs to PidRef structures for tracking session leaders could cause inconsistencies in session management, potentially leading to a disconnect between system resources (like eth0) and their associated sessions. If the new session doesn't maintain the same references or associations, it might lead to eth0 being removed.

Session Termination/Reset:
If sessions are reset or terminated upon resuming, this might trigger a re-initialization of system resources. If eth0 is tied to a session that is no longer valid or has been reset, it could be removed.

Now the question is: If manually i turn on networkmanager somehow (hook.sh), then internet work fine without reboot. BUT apps that was online before suspend t after resume cant connet to internet even if somehow we managed to turn on internet. So is this PIDs to PidRef structures also might be the reason ?

Answer:
Yes. This change might have implications on how sessions are managed and, subsequently, how system resources like network interfaces are tied to sessions.

Here's why this could be the case:

Session Identification:
If PidRef affects session identification, then resources (like network interfaces) linked to those sessions might be disrupted when a session is reset, redefined, or reinitialized. When the system is suspended and then resumed, if the session handling has changed due to PidRef, it could lead to a disconnect between network interfaces and their associated sessions.

Resource Re-Initialization:
If sessions are reset or re-initialized after suspension, resources tied to those sessions might also need re-initialization. In this case, while NetworkManager might be turned on, individual applications relying on the original session might still have issues because their context or environment has changed. This would explain why NetworkManager can be "manually" activated, but applications still experience connectivity issues.

Process Handling:
If the change to PidRef affects how session leaders are tracked, it could impact the process lifecycle within those sessions. If an application's process relies on a stable session leader and that leader changes, it could cause communication issues between processes or between a process and its resources.

Therefore, this behavior could indeed be linked to the transition to PidRef, where session management inconsistencies or changes affect system resources and cause applications to lose their network context. ie hook.sh turn on networkmanager but email client which was online before suspend can read old news but no new...

just thoughts...

rizitis · 04-21-2024, 11:01 AM

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

rizitis · 04-21-2024, 12:08 PM

I rebuild elogind according to this commit and rebuild current polkit against elogind and things looks work fine
can you confirm please.

LuckyCyborg · 04-21-2024, 12:11 PM

Quote:

Originally Posted by rizitis

I rebuild elogind according to this commit and rebuild current polkit against elogind and things looks work fine

Same here. Fortunately, right now this thread is really [SOLVED] ...

LuckyCyborg · 04-21-2024, 12:16 PM

Quote:

Originally Posted by z80

Yes, the bug in elogind is not fixed but Slackware is working again (for me).

BUT the thread title does not talk about your sorry ass, but about a "Bug with elogind-255.4-r2" which is not yet officially fixed.

You do not think that marking this thread as [SOLVED] would confuse the people?

But of course, you do not care about confusing people, right?

kgha · 04-21-2024, 12:30 PM

Quote:

Originally Posted by LuckyCyborg

Same here. Fortunately, right now this thread is really [SOLVED] ...

Or will be, as soon as the commit has been made part of a new release and there's an official slackware package

Oh, and BTW I've rebuilt elogind and polkit too and it works fine here as well.