Hi Marc, thank you for the quick reply.
On Fri, Feb 27, 2026 at 03:41:43AM +0900, Marc Dequènes (duck) wrote: > You're simply using this kind of configuration? > [initial_session] > command = "sway" > user = "myuser" Yes, exactly. > I have never used this feature but that's a legitimate use case. Glad to hear that. > Why are you mentioning rtkit, is there anything at this stage that requires > it? I looked into the system and user journal. From there it is evident that a user session is being started, but it also terminates quickly. So I think greetd actually launches sway, something fails and then it just spawns agreeter. So I looked for services that were started after my user session being started. I spot at least rtkit and dbus-broker. There probably is more. I am aware that pipewire uses rtkit and that multiple pieces of my session talk to dbus. Hence I figured they could be relevant. > I'm not using dbus-broker, it is doing a Before=basic.target and > Requires=dbus.socket while dbus-daemon does not have the Before. > Except for this the configuration is similar although I wonder why > dbus-broker uses DefaultDependencies=false and manually adds what this > option would have added. I suspect that dbus vs dbus-broker does not pose a difference here. I am also observing the behavior on another trixie system that uses plain dbus instead of dbus-broker. I do not suggest changing greetd in trixie. > So it would not seem to be the reason. I honestly do not know nor understand what makes my user session fail. Those were wild guesses and not very plausible ones. > > If I later remove /run/greetd.run, and systemctl restart greetd, > > autologin reliably works. > > Why would you need to remove the file manually? the restart should take care > of that. When greetd uses /run/greetd.run as a flag file to see whether it is started for the first time of this boot. When the file exists, it does not launch an initial_session. It only launches it when first being started during boot. > > How do we want to move from here? > > 1. Declare not-a-bug. If I reconfigue greetd to launch a payload that > > requires further service, it is my responsibility to declare them. > > 2. Find out what services are typically required and list them > > explicitly in the systemd unit. (How?) > > 3. Declare After=basic.target. This may defer the presentation of the > > greeter more than necessary, but for me it was hardly noticeable. It > > also saves us from figuring out what the correct dependency is. > > > > If you choose 1, please tag wontfix and close. > > I would prefer option 2 but I don't know yet how to find the dependencies. Ok, I can keep trying a bit. Possibly, we can replicate this in a debvm. Though not right now. > I looked at what basic.target entails on my system and it drags > remote-fs.target/nfs-client.target so in certain configuration that could > lead to a certain delay. Yes. It can incur quite some delay. For my system the additional delay happens to not be noticeable, but that may vary. basic.target was an easy way to just delay it sufficiently. > Although gdm3 does After=rc-local.service which in turns requires > basic.target, I'm not sure it's the way to go. lightdm has the same > dependencies as greetd (or maybe I took inspiration from it). If I have time > I'll try to check the impact on the delay. Thank you! > In my situation I use LDAP auth and never experienced any problems but maybe > I'm not typing fast enough. Do you need any remote mount or user resolution > that requires network access? Not at all. In both of my applications, it is a local user that directly launches into a wayland compositor. That tends to be fast. Helmut
