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 09:01:46 +0000

Hi Nathan,

On Sun, Jan 25, 2026 at 12:30:07AM +0000, [email-masked] wrote:
> On Saturday, January 24th, 2026 at 17:34, Andrew Bower <[email-masked]> 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 [email-masked], 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