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:21:45 +0000

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.

> Kudos!

Thanks for being prepared to try an untested patch!