interface down after resuming from standby, Network Manager loosing Ethernet connection (Re: elogind/runit-services breakage)

Martin Steigerwald martin at lichtvoll.de
Mon Apr 15 17:46:06 BST 2024


Martin Steigerwald - 15.04.24, 18:33:02 CEST:
> Dimitris - 15.04.24, 11:52:08 CEST:
> > can confirm this..
> > seems like a serious issue seen after latest elogind upgrade (255).
> > 
> > udevd dmesg (various such messages) : "failed to execute
> > '/lib/udev/libexec/elogind-uaccess-command'
> > 'libexec/elogind-uaccess-command /dev/XXXXXX' : no such file or
> > directory
> > 
> > elogind-uaccess-commnad is currently found at /usr/libexec/
> 
> Mmmh, I wonder how many other things like this show up.
> 
> Currently I still have a very strange issue that may be related to this:
> 
> I close the lid of my ThinkPad T14 AMD Gen 1.
> 
> I open it again.
> 
> Ethernet based network is gone. "ip link" shows the link as down.
> 
> What currently kind of works for me is:
> 
> 1) "ip link set LINK up" on the link
> 
> 2) Terminate the Network Manager process so runit starts a new one.
> 
> 3) killall plasmashell ; plasmashell
> 
> 4) Reconnect via Network Manager applet.
> 
> Trying to fix the path issue manually now:
> 
> […]/lib/udev# grep -ir elogind-uaccess-command
> rules.d/73-seat-late.rules:TAG=="uaccess", ENV{MAJOR}!="", RUN{program}
> +="libexec/elogind-uaccess-command %N $env{ID_SEAT}"
> 
> Changed path to absolute path "/usr/libexec/elogind-uaccess-command" in
> there.

Error message is gone from dmesg. Unfortunately the network issue is
still there. Link looks like this after resuming from standby:

% ip link sh en1
3: en1: <BROADCAST,MULTICAST> mtu 1500 qdisc fq_pie state DOWN mode DEFAULT group default qlen 1000

(I renamed link via udev rule)

And I found this in dmesg on boot:

[   33.115650] elogind-daemon[2616]: Failed to connect to system bus: No such file or directory
[   33.116364] elogind-daemon[2616]: Failed to fully start up daemon: No such file or directory

Could this also be some file related issue? I did not find anything so far.

Not being able to communicate with the system bus could mean that Network
Manager is not informed properly about the suspend to standby / resume cycle.

Best,
-- 
Martin





More information about the Debian-init-diversity mailing list