On Mon, Mar 17, 2025 at 11:23:26AM +0100, Lorenzo wrote:
> On Mon, 17 Mar 2025 06:49:37 +0000
> Mark Hindley <mark@???> wrote:
>
> > On Mon, Mar 17, 2025 at 01:10:57AM +0100, Lorenzo wrote:
> > > > I suspect it's the elogind check script (/etc/sv/elogind/check).
> > > > Let's bring in Lorenzo.
> > >
> > > very likely; since dbus, elogind and login managers are started at
> > > the same time, I'd expect elogind check at least to fail once at
> > > boot.
> >
> > Wouldn't it be better to start dbus first?
> >
> > Mark
>
> yeah, we already do that, (elogind waits for dbus) but the way the
> start "sequence" works in runit imply that the elogind check file is
> run to check whether elogind is available when starting a login manager
> and there is no guarantee that elogind is ready in the first iteration.
> I guess Andrew is using a login manager that has no hard dependency on
> dbus so the run file, after checking for dbus proceeds on checking for
> elogind even if dbus is not ready yet ..
> Andrew, are you using slim or sddm ?

slim:

sv start dbus || true
sv start elogind || true

But 'sv start' will run the check script, won't it, which now tests a
dbus 'ping'.

So probably on my system it is what we (I) recently added [1],

docker:

sv start elogind

But I don't think we want to start encoding transitive dependencies
which aren't also first class dependencies, so I think we just divert
stderr in the dbus check file as you first suggested!

-Andrew

[1] https://salsa.debian.org/debian/runit-services/-/commit/047d1c88479f0ab750bacdb45a1113d1269641b4