AIUI, the supported method for launching background daemons that also set environment variables under Plasma is ~/.config/plasma-workspace/env/*.sh. Under X11, the $DISPLAY environment variable exists when these scripts are sourced. However, under Wayland, these scripts are sourced before the compositor is started and $WAYLAND_DISPLAY does not exist. This makes it impossible to launch ssh-agent and use it interactively, e.g. with SSH_ASKPASS=ksshaskpass because ksshaskpass has no idea what display to start in. I suspect the env scripts ought to be sourced from /usr/lib/startplasma (after kwin_wayland starts), not /usr/bin/startplasmacompositor. Or perhaps there should be two config directories, one for pre-compositor scripts and one for post-compositor scripts. Ugly workarounds are possible, of course (e.g. an autostart script that dumps the required variables somewhere, and an sshaskpass wrapper that pulls them in), but there should clearly be a better way.
Ideally we shouldn't have anything interactive in env/*.sh because they'll block the login process; and it's at a point where we have no control over what is drawn on the root window. We certainly can't move those scripts. Having two dirs could be possible.
To be clear, the problem isn't that this is an interactive process *when those scripts are executed*, it's that the appropriate display environment variables need to be available so they are inherited by an intearctive child process at a later time, in response to a user request. For now I resorted to the aforementioned hack of wrapping ksshaskpass in a script that sources the display environment variables from somewhere else filled in by an autostart script. ssh-agent still starts from env/, but now the script it calls injects the right variables before execing ksshaskpass. I did have to set DISPLAY to a dummy value in the parent script, though, because ssh-agent checks that it is set before even trying to call askpass...
What's your plan? To launch ssh-agent in Wayland on startup? What's your solution now? I'm looking into providing the same ssh-agent functionality in Wayland session as in X. So I'm looking for info about it.
(In reply to Roman Gilg from comment #3) > What's your plan? To launch ssh-agent in Wayland on startup? What's your > solution now? > > I'm looking into providing the same ssh-agent functionality in Wayland > session as in X. So I'm looking for info about it. Is there anything we can learn from GNOME? I found they had something related: https://bugzilla.gnome.org/show_bug.cgi?id=772919
Had a discussion at Akademy: Short term. I think one can do ssh-agent as you are now *THEN* set SSH_ASKPASS it will then be interactive on the next ssh-add or whatever by which time you should have a display manager you can connect to. (untested) ------ Longer term: kwin will be a systemd service, only consider "started" after it has launched the display socket plasmashell (et al) will be a target also as a service putting ssh-agent between the two and being sure to run dbus-update-activation-env --systemd at the end of the script would then work.
(In reply to David Edmundson from comment #5) > Longer term: > > kwin will be a systemd service, only consider "started" after it has > launched the display socket > plasmashell (et al) will be a target also as a service > > putting ssh-agent between the two and being sure to run > dbus-update-activation-env --systemd at the end of the script would then > work. I guess this longer term goal is now unblocked?
Looks like it, yeah.
With systemd startup and everything in slices, if I run `ssh-add -q < /dev/null` in a Wayland session, ksshaskpass runs normally and seems to work. Will that suffice for your purposes?
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone!
(In reply to Nate Graham from comment #8) > With systemd startup and everything in slices, if I run `ssh-add -q < > /dev/null` in a Wayland session, ksshaskpass runs normally and seems to > work. Will that suffice for your purposes? I'm not original reporter but SSH works much better for me in Plasma 5.21.5 (on Wayland). Note that I use gnuk token with gpg-agent, so somewhat different setup.