Subject: bug#937: 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 19:40:56 +0000

On Sun, Jan 25, 2026 at 07:21:45PM +0000, Andrew Bower wrote:
> On Sun, Jan 25, 2026 at 07:14:58PM +0000, [email-masked] wrote:
> > On Sunday, January 25th, 2026 at 13:06, Andrew Bower <[email-masked]> wrote:
> > > I have a hunch this will do it...
> > > 
> > > The error is indeed coming from a call that will cause failure. Setting
> > > this argument to 'true' will deconfigure use of the notify socket once
> > > we've signalled readiness.
> > > 
> > > $ git diff
> > > diff --git a/src/shared/daemon-util.h b/src/shared/daemon-util.h
> > > index 711885bba..6823cc31d 100644
> > > --- a/src/shared/daemon-util.h
> > > +++ b/src/shared/daemon-util.h
> > > @@ -12,7 +12,7 @@
> > > 
> > > static inline const char *notify_start(const char *start, const char *stop) {
> > > if (start)
> > > - (void) sd_notify(false, start);
> > > + (void) sd_notify(true, start);
> > > 
> > > return stop;
> > > }
> > 
> > Winner, winner!  This seems to do the trick, with an unmolested elogind initscript (255.17-4).
> 
> Exellent!
> 
> Now I don't reckon this is a good enough production patch because
> someone could write a service manager (that isn't systemd!) that wanted
> to use the sd readiness protocol for the whole life of a service.
> 
> I think we need to change pid_notify_with_fds_internal() in
> src/shared/daemon-util.h so that if the send fails with ENOENT, the call
> returns successfully and unsets NOTIFY_SOCKET from the environment:
> 
>   n = sendmsg(fd, &msghdr, MSG_NOSIGNAL);
>   if (n < 0) {
>           if (!send_ucred)
>                   return log_debug_errno(errno, "Failed to send notify message to '%s': %m", e);
> 
> I'm not 100% sure this is the right thing always to do so a carefully
> constructed comment might be appropriate to warn future developers of
> why we did it. A safe thing to do would be to return success but not
> clear the environment but it would be nice to stop repeated pointless
> behaviour.

Nah, changed my mind. We shouldn't really modify the implementation
under sd_notify() which inherits loads of stuff from libsystemd which
could be substituted one day with a simpler version.

Instead we should find out exactly what is calling sd_notify() at these
later points and make it handle the -errno style error code
appropriately. I can't see where this is getting called.

We could hack s-s-d to keep showing us or hack elogind to print them
out. One quick way might be to hack src/shared/daemon-util.h
NOTIFY_READY definition to misspell 'READY' as 'REAxDY' and whack a big
--notify-timout into START_ARGS; then s-s-d will keep waiting and
printing everything it gets from elogind and we can trace it that way.