Hello,
thanks for maintaining greetd. I tried using it to autologin a user with
sway. This can be sensible e.g. when using full disk encryption or when
using greetd to implement a kiosk-style system. I am observing that
greetd is started relatively early. At least rtkit and dbus-broker are
started after greetd spawns sway. In the end the login session fails
(with no clear indication why).
If I later remove /run/greetd.run, and systemctl restart greetd,
autologin reliably works.
Once I added After=basic.target to greetd.service, I did not observe
failed logins anymore.
I recognize that autologin is a non-default configuration and that the
problem likely does not affect typical prompters such as agreety nor its
default configuration.
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.
Helmut
Quack, You're simply using this kind of configuration? [initial_session] command = "sway" user = "myuser" I have never used this feature but that's a legitimate use case. Why are you mentioning rtkit, is there anything at this stage that requires it? 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. So it would not seem to be the reason. Why would you need to remove the file manually? the restart should take care of that. I would prefer option 2 but I don't know yet how to find the dependencies. 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. 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. 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? Regards. \_o<
Quack, You're simply using this kind of configuration? [initial_session] command = "sway" user = "myuser" I have never used this feature but that's a legitimate use case. Why are you mentioning rtkit, is there anything at this stage that requires it? 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. So it would not seem to be the reason. Why would you need to remove the file manually? the restart should take care of that. I would prefer option 2 but I don't know yet how to find the dependencies. 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. 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. 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? Regards. \_o<
Hi Marc, thank you for the quick reply. Yes, exactly. Glad to hear that. 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 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. I honestly do not know nor understand what makes my user session fail. Those were wild guesses and not very plausible ones. 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. Ok, I can keep trying a bit. Possibly, we can replicate this in a debvm. Though not right now. 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. Thank you! 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
Hi Marc, debvm-create -o greetd.debvm -r unstable -- --include=foot,greetd,libpam-systemd,linux-image-amd64,sway --hook-dir=/usr/share/mmdebstrap/hooks/useradd debvm-run -i greetd.debvm -g Some explanation: * foot is useful as sway is relatively useless without a terminal or menu. * greetd is what we are testing. * Without libpam-systemd, nothing sets up XDG_RUNTIME_DIR and sway gets unhappy. * We request linux-image-amd64 instead of the default linux-image-cloud-amd64 to get graphics drivers. * sway is our target command from greetd. * The useradd hook is quite clever. It causes a non-root user (default "user") to be added. It also attempts to configure automatic login by various means including lightdm and *drumroll* greetd. So it takes care of editing the config.toml and adding the initial_session section you mentioned earlier. * The -g option for debvm-run requests graphical mode. This test case is unreliable. Try booting the machine several times. I am storing the debvm image on tmpfs to rule out speed variance from the storage stack. I tried this both with and without dbus-broker and got similarly mixed results. Sometimes, sway starts and sometimes it fails. In the minimal example (compared to the physical system I earlier tried), I am not seeing much going on after greetd is being started. I tried adding After=basic.target, but even that did not reliably fix it. Thanks for insisting to dig deeper as my naive workaround evidently is insufficient. Ansgar pointed out that systemd-cat cant redirect a given command's output to the journal. So I attempted wrapping sway in systemd-cat and got an error: | 00:00:00.003 [ERROR] [wlr] [backend/session/session.c:331] Failed to open device '/dev/dri/card0': Resource temporarily unavailable Not sure what we can do about this. Apparently one reason for this can be that the vt is not active. However, greetd's switch defaults to true and has not been changed, so it really should be active. I'm a bit lost as to what we can do here. At least we have an (unreliable) test case now. Would you be able to independently verify my reproducer? Any further ideas for debugging? Helmut
Quack, I did not know this tool, very handy and the setup is fast :-). With or without After=basic.target I was not once able to get it to work. I was able to get the error with a quick screenshot (attached). https://github.com/systemd/systemd/issues/25408 Unfortunately there is no clear solution in this ticket or around. I need to dig more into it. Regards. \_o<