On 25.12.2022 15:13, mh@mike.franken.de wrote:
On Sonntag, 25. Dezember 2022 11:10:26 CET Mark Gray wrote:
See: After update: when ssh'ing to other 15.4: Invalid environment assignments https://bugzilla.opensuse.org/show_bug.cgi?id=1206500
"Invalid environment assignment" is rather different from "Process org.freedesktop.systemd1 exited with status 1", is not it?
Basically there is some bash function in your environment that dbus-update-activation-environment misinterprets as a variable and systemd objects. In my case the "mc" package added a "mc" bash function that causes the problem. Removing the "mc" package fixes the bug. In the case of the poster of the bug it was "lua-lmod".
If you add --verbose to the end of the call to dbus-update-activation-environment it will tell you which bash function is screwing up for you. I suspect that the command should not use "--all" and list only the precise environment variables that systemd should know about, but I am not a SuSE employee so I have no way of telling which variables they wanted to send.
On my machine the error message is shown for every variable.
Which error message? The one you reported originally or the one in bug report in this post?
I tried to do exactly what you suggested - set one variable at a time.
Set it where? On client where you do "ssh server" or on server into which you ssh? From your original post it is not even clear whether you patched client or server and what is running Leap 15.4 - client or server. I cannot reproduce this when logging *into* Leap 15.4. Reproducing "invalid variable assignment" is trivial, but that is not your problem. The error in the subject is expected if D-Bus daemon attempts to auto-spawn systemd. But systemd user instance should be already started by pam_systemd. Show output of "ps -fu <your-user>" after logging in via ssh.