Devuan bug report logs - #937
elogind: SwayWM fails to launch from vTTY: Could not take device: No such file or directory

Full log

Message #92 received at 937@bugs.devuan.org (full text, mbox, reply):

Received: (at 937) by bugs.devuan.org; 25 Jan 2026 19:42:21 +0000
Return-Path: <andrew@bower.uk>
Delivered-To: bugs@devuan.org
Received: from email.devuan.org [2a01:4f9:fff1:13::5fd9:f9e4]
	by doc.devuan.org with IMAP (fetchmail-6.4.39)
	for <debbugs@localhost> (single-drop); Sun, 25 Jan 2026 19:42:21 +0000 (UTC)
Received: from email.devuan.org
	by email.devuan.org with LMTP
	id qhadEc1xdmlHCAAAmSBk0A
	(envelope-from <andrew@bower.uk>)
	for <bugs@devuan.org>; Sun, 25 Jan 2026 19:41:01 +0000
Received: by email.devuan.org (Postfix, from userid 109)
	id 12FB6390; Sun, 25 Jan 2026 19:41:00 +0000 (UTC)
Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=2a00:1098:0:82:1000:0:2:1; helo=mx2.mythic-beasts.com; envelope-from=andrew@bower.uk; receiver=bugs.devuan.org 
Received: from mx2.mythic-beasts.com (mx2.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1])
	by email.devuan.org (Postfix) with ESMTPS id A729D4F
	for <937@bugs.devuan.org>; Sun, 25 Jan 2026 19:40:58 +0000 (UTC)
Received: by mailhub-hex-d.mythic-beasts.com with esmtpsa  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
	(Exim 4.96)
	(envelope-from <andrew@bower.uk>)
	id 1vk5yj-0047oq-0Z;
	Sun, 25 Jan 2026 19:40:57 +0000
Received: from andy by shenstone.ab8.net with local (Exim 4.99.1)
	(envelope-from <andrew@bower.uk>)
	id 1vk5yi-000000005Ni-3pcZ;
	Sun, 25 Jan 2026 19:40:56 +0000
Date: Sun, 25 Jan 2026 19:40:56 +0000
From: Andrew Bower <andrew@bower.uk>
To: public@desmas.net
Cc: Mark Hindley <mark@hindley.org.uk>, 937@bugs.devuan.org
Subject: Re: elogind: SwayWM fails to launch from vTTY: Could not take
 device: No such file or directory
Message-ID: <aXZxyIz3dx-EcRoK@shenstone.ab8.net>
References: <Ebb3IokxY5iTIfgVS7a1A2GzbW2UyI4bLwvQybbY1V0tvbG29LH7QxEBQlfYw3MEcr8LFjHBsyBB_dnkNpjvZT1w9hDErAIhSyuunHTVfjY=@desmas.net>
 <aXX6bc32OL9pq5Od@shenstone.ab8.net>
 <AjiPqLeGnaXYHikPoKEtmYFHJZ3levS3USxQ1D9RRqAb2-AxK6C8sEghJhdPu9hGmM3XemacXuJblCOYHkdwqHdFPaM4POuQ5rQFa2IsQFc=@desmas.net>
 <TApNvbVBVivJwgIYZqIIXozxt3Sy3vJbp5sJLK0wI28obQhFrxOul9aGYozJKN-Xoumx1vpNV9XhVgR6ohxmZBlGyUb89StfNl6GaKcqqQY=@desmas.net>
 <aXZkkvwiIbWp_Jd-@shenstone.ab8.net>
 <aXZmH-qltlHnhqwr@shenstone.ab8.net>
 <5lwDWAzFVgO0qJvAwWKDgJDugs-J0m_YmZuHh-EiotjlVKsI3mtqLpJrW5hsG_qHXYcb1mbEkCpF6Rg-H8u8lrIO5tVhqQLIJOiZLUaEj48=@desmas.net>
 <aXZpxAlx-TsyvpRh@shenstone.ab8.net>
 <7mNBwywdoAN79Oaj5pO9iAzPG3ta4A_iwhFdrl82DopmmP88qhVyH9s-Fml5_8XvGxZHotFzH1pAfqif16VsKFaPho1iSLgAIS4Qh4aZ7cI=@desmas.net>
 <aXZtSb99Wa3n5bNw@shenstone.ab8.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <aXZtSb99Wa3n5bNw@shenstone.ab8.net>
User-Agent: Mutt/2.2.13 (2024-03-09)
X-BlackCat-Spam-Score: 0
X-Spam-Status: No, score=0.0

On Sun, Jan 25, 2026 at 07:21:45PM +0000, Andrew Bower wrote:
> On Sun, Jan 25, 2026 at 07:14:58PM +0000, public@desmas.net wrote:
> > On Sunday, January 25th, 2026 at 13:06, Andrew Bower <andrew@bower.uk> 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.

Send a report that this bug log contains spam.