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

Full log

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

Received: (at 937) by bugs.devuan.org; 25 Jan 2026 09:03:02 +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 09:03:02 +0000 (UTC)
Received: from email.devuan.org
	by email.devuan.org with LMTP
	id 9rBzAADcdWk6IwAAmSBk0A
	(envelope-from <andrew@bower.uk>)
	for <bugs@devuan.org>; Sun, 25 Jan 2026 09:01:52 +0000
Received: by email.devuan.org (Postfix, from userid 109)
	id BFBEC33E; Sun, 25 Jan 2026 09:01:51 +0000 (UTC)
Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=2a00:1098:0:86:1000:0:2:1; helo=mx1.mythic-beasts.com; envelope-from=andrew@bower.uk; receiver=bugs.devuan.org 
Received: from mx1.mythic-beasts.com (mx1.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1])
	by email.devuan.org (Postfix) with ESMTPS id 5F3C89F
	for <937@bugs.devuan.org>; Sun, 25 Jan 2026 09:01:49 +0000 (UTC)
Received: by mailhub-cam-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 1vjw0B-004qzh-1F;
	Sun, 25 Jan 2026 09:01:47 +0000
Received: from andy by shenstone.ab8.net with local (Exim 4.99.1)
	(envelope-from <andrew@bower.uk>)
	id 1vjw0A-000000004vs-0vvP;
	Sun, 25 Jan 2026 09:01:46 +0000
Date: Sun, 25 Jan 2026 09:01:46 +0000
From: Andrew Bower <andrew@bower.uk>
To: public@desmas.net, Mark Hindley <mark@hindley.org.uk>
Cc: 937@bugs.devuan.org
Subject: Re: elogind: SwayWM fails to launch from vTTY: Could not take
 device: No such file or directory
Message-ID: <aXXb-qCA_8lUBWWc@shenstone.ab8.net>
References: <176919624261.27301.12565388510718151229.reportbug@desmas-l-fa617xt.desmas>
 <aXTxAewx_Dfipw1f@shenstone.ab8.net>
 <-8H38rMe5nzcSivo6VBrcez-Wwy0MWKC2B2Zd0tdxrPv5su8HOQ7jwPvqw9hCvY_xLWV7Q2SgaHim2Vl1iyuX9G9j7-r103tRu95Ns3fiQ8=@desmas.net>
 <aXVXGa2LGtvhCkbb@arden.ab8.net>
 <zmT_m_nKXVguZywkFoxgaimZF7OJ5qhOxfE1E9bnGso6Dx6upPrMjSo-R-3oLmWpYWUgBBZ1HqS_wtNTqxeWhYw5Y3P04WztnR4jY9dEamg=@desmas.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <zmT_m_nKXVguZywkFoxgaimZF7OJ5qhOxfE1E9bnGso6Dx6upPrMjSo-R-3oLmWpYWUgBBZ1HqS_wtNTqxeWhYw5Y3P04WztnR4jY9dEamg=@desmas.net>
User-Agent: Mutt/2.2.13 (2024-03-09)
X-BlackCat-Spam-Score: 0
X-Spam-Status: No, score=0.0

Hi Nathan,

On Sun, Jan 25, 2026 at 12:30:07AM +0000, public@desmas.net wrote:
> On Saturday, January 24th, 2026 at 17:34, Andrew Bower <andrew@bower.uk> wrote:
> > One small thing to try, could you add '--verbose --no-close' to
> > START_ARGS?
> 
> It appears log messages from elogind would go to /var/log/auth.log; is this correct? I see nothing different with --verbose and --no-close options.

Sorry I didn't explain what I was thinking: I was trying to eliminate
differences between how elogind daemonizes itself and how
start-stop-daemon (s-s-d) daemonizes services. One is that the latter
redirects stdio to /dev/null so --no-close was to stop that as I don't
have much else to try!

--verbose was just a bonus while making another change, and is for
diagnostics from s-s-d itself showing the readiness notification
protocol.


> Looking at the elogind source, it appears I may need to rebuild it with ENABLE_DEBUG_ELOGIND and/or LOG_TRACE:
> 
> - https://git.devuan.org/devuan/elogind/src/branch/master/src/basic/log.h#L235
> - https://git.devuan.org/devuan/elogind/src/branch/master/src/basic/log.h#L241
> - https://github.com/elogind/elogind/blob/88c346cdc5ef231465552de9c55332fd9d2c408b/meson.build#L1248
> 
> It's also not clear what --verbose should impact, looking briefly at the source.

See above, this wasn't an option for elogind.

> 
> kennylevinsen, via #sway@irc.libera.chat, has told:
> 
> > 14:56 < kennylevinsen> well the main things to look for: 1. is elogind still running as root? it has to, 2. is the test being run after the GPU is available (if you're starting sway itself from an init script you can be too fast)
> > 14:59 < kennylevinsen> worst case you could edit the init script to strace elogind
> > 15:00 < kennylevinsen> but no I don't quite know what that init system does and why it might have broken it
> 
> 1. elogind does run as root

It does run as root but I wonder if some privilege has somehow got lost
in the different daemonization process. This might give us some clues:

  cat /proc/$(cat /run/elogind.pid)/status

Anyone could check that between the two modes - doesn't need to be in
your system where the failure is occurring.

> 2. I assume the GPU is still available; I have not altered anything but the init script due to upgrade, and flopping back/forth to daemon/notify in the same boot functions as expected.
> 
> I think to rebuild elogind with debug logging before wading through strace logs.

That indeed might help.

Mark,

Now we have two users badly and reliably affected with different
scenarios, no smoking gun and I don't really have time today to debug,
do you think we should revert the startup semantics and reopen #935?

I still think #935 is worth doing to get robust setups all round that
aren't susceptible to random timing issues, but I think we need to
reproduce Nathan's failure, root cause and fix.

We can keep the new init-d-script as that's been proven not to be the
problem, we just need to have:

  DAEMON_ARGS='-D'
  START_ARGS=''

It may be that when root-caused, the fix needs to go in s-s-d. I'll also
keep reviewing that implementation by inspection and comparing with
elogind.

Andrew

Send a report that this bug log contains spam.