Subject: Re: elogind: SwayWM fails to launch from vTTY: Could not take device: No such file or directory

From: Andrew Bower <[email-masked]>
Date: Sun, 25 Jan 2026 18:51:11 +0000

On Sun, Jan 25, 2026 at 06:44:34PM +0000, Andrew Bower wrote:
> On Sun, Jan 25, 2026 at 06:21:25PM +0000, [email-masked] wrote:
> > I've built elogind packages with log-trace: true and debug-extra: ['elogind'], and it provides more detail, e.g.:
> > 
> > > elogind[13734]: Got message type=method_call sender=:1.30 destination=org.freedesktop.login1 path=/org/freedesktop/login1/session/_38 interface=org.freedesktop.login1.Session member=TakeDevice  cookie=10 reply_cookie=0 signature=uu error-name=n/a error-message=n/a
> > > elogind[13734]: Failed to send notify message to '/run/.s-s-d-notify.49UVq6/notify': No such file or directory
> > > elogind[13734]: Sent message type=signal sender=n/a destination=:1.30 path=/org/freedesktop/login1/session/_38 interface=org.freedesktop.login1.Session member=PauseDevice cookie=76 reply_cookie=0 signature=uus error-name=n/a error-message=n/a
> > > elogind[13734]: Sent message type=error sender=n/a destination=:1.30 path=n/a interface=n/a member=n/a cookie=77 reply_cookie=10 signature=s error-name=org.freedesktop.DBus.Error.FileNotFound error-message=No such file or directory
> > > elogind[13734]: Failed to process message type=method_call sender=:1.30 destination=org.freedesktop.login1 path=/org/freedesktop/login1/session/_38 interface=org.freedesktop.login1.Session member=TakeDevice cookie=10 reply_cookie=0 signature=uu error-name=n/a error-message=n/a: No such file or directory
> 
> Oh this is interesting.
> 
> Since the initial readiness exchange seems to work OK, I wonder if

Just to confirm this with you - when you added '--verbose' to
START_ARGS, did the output confirm to you:

 -> Notification => ready for service.

? If you only relied on reboot then 'service elogind start' should show
this.

> what's happening is elogind continues to send information over this
> channel through its lifetime despite the fact it is now closed, and I
> wonder if it then takes some wrong code paths which prevents it from
> performing its main function properly.
> 
> It might be worth it looking at the places that elogind tries to signal
> a notification and make sure failure to signal on a closed channel is
> ignored and doesn't cause a broader error.