dbus-update-activation-environment: warning: error sending to systemd: org.freedesktop.DBus.Error.Spawn.ChildExited: Process org.freedesktop.systemd1 exited with status 1
Hi, after patching my Leap 15.4 machines with the latest hotfixes today, I get dbus-update-activation-environment: warning: error sending to systemd: org.freedesktop.DBus.Error.Spawn.ChildExited: Process org.freedesktop.systemd1 exited with status 1 when logging in via ssh. Any idea, what to do to solve this problem? TIA. Bye. Michael.
On 23.12.2022 17:38, mh@mike.franken.de wrote:
Hi,
after patching my Leap 15.4 machines with the latest hotfixes today, I get
dbus-update-activation-environment: warning: error sending to systemd: org.freedesktop.DBus.Error.Spawn.ChildExited: Process org.freedesktop.systemd1 exited with status 1
when logging in via ssh.
Any idea, what to do to solve this problem?
Start with finding out what invokes dbus-update-activation-environment during login.
On 12/23/22 08:28, Andrei Borzenkov wrote:
On 23.12.2022 17:38, mh@mike.franken.de wrote:
Hi,
after patching my Leap 15.4 machines with the latest hotfixes today, I get
dbus-update-activation-environment: warning: error sending to systemd: org.freedesktop.DBus.Error.Spawn.ChildExited: Process org.freedesktop.systemd1 exited with status 1
when logging in via ssh.
Any idea, what to do to solve this problem?
Start with finding out what invokes dbus-update-activation-environment during login.
For the record, I started seeing this too on dozens of 15.4 hosts. It doesn't seem to affect anything that I'm aware of. How would we find out what's invoking it during login? Regards, Lew
On 23.12.2022 19:59, Lew Wolfgang wrote:
On 12/23/22 08:28, Andrei Borzenkov wrote:
On 23.12.2022 17:38, mh@mike.franken.de wrote:
Hi,
after patching my Leap 15.4 machines with the latest hotfixes today, I get
dbus-update-activation-environment: warning: error sending to systemd: org.freedesktop.DBus.Error.Spawn.ChildExited: Process org.freedesktop.systemd1 exited with status 1
when logging in via ssh.
Any idea, what to do to solve this problem?
Start with finding out what invokes dbus-update-activation-environment during login.
For the record, I started seeing this too on dozens of 15.4 hosts. It doesn't seem to affect anything that I'm aware of.
bor@10:~> cat /etc/profile.d/openssh-dbus.sh if test -n "$SSH_CONNECTION" -a -n "$DISPLAY" then dbus-update-activation-environment --systemd --all fi bor@10:~> rpm -q --changelog openssh-server | less * Wed Jun 22 2022 vliaskovitis@suse.com - Add openssh-dbus.sh, openssh-dbus.csh, openssh-dbus.fish: Make ssh connections update their dbus environment (bsc#1179465). https://bugzilla.opensuse.org/show_bug.cgi?id=1179465 You are not authorized to access bug #1179465. So much about "community distribution".
See: After update: when ssh'ing to other 15.4: Invalid environment assignments https://bugzilla.opensuse.org/show_bug.cgi?id=1206500 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 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
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. I tried to do exactly what you suggested - set one variable at a time.
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.
On Sonntag, 25. Dezember 2022 14:21:20 CET Andrei Borzenkov wrote:
On 25.12.2022 15:13, mh@mike.franken.de wrote: [...]
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?
I modified /etc/profile.d/openssh-dbus.sh and added --verbose to dbus-update-activation-environment --systemd --all. Then I copied some of the lines shown and modified /etc/profile.d/openssh-dbus.sh again, so that it looks like if test -n "$SSH_CONNECTION" -a -n "$DISPLAY" then dbus-update-activation-environment --systemd --verbose HOSTTYPE="x86_64" ... fi
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.
The server is running Leap 15.4, the clients are running different flavors of Unix and Windows. I thought it would be clear, that the server is running Leap, because it shows the error messages. Btw. on Tumbleweed the openssh profile still does not exist, so ...
I cannot reproduce this when logging *into* Leap 15.4. Reproducing "invalid variable assignment" is trivial, but that is not your problem.
Nope.
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.
Yep, systemd-user is running already.
Show output of "ps -fu <your-user>" after logging in via ssh.
UID PID PPID C STIME TTY TIME CMD myuser 2352 1 0 Dez23 ? 00:00:03 /usr/bin/syncthing serve --no- browser --no-restart --logflags=0 myuser 2531 2352 0 Dez23 ? 00:17:30 /usr/bin/syncthing serve --no- browser --no-restart --logflags=0 myuser 10378 26796 0 14:36 pts/1 00:00:00 /bin/ps -fu myuser myuser 26670 1 0 11:09 ? 00:00:00 /usr/lib/systemd/systemd --user myuser 26671 26670 0 11:09 ? 00:00:00 (sd-pam) myuser 26676 26667 0 11:09 ? 00:00:00 sshd: myuser@notty myuser 26701 1 0 11:09 ? 00:00:00 dbus-launch --autolaunch 06de7a452f09bc3e8eb5225dc9fbee00 --binary-synta myuser 26702 1 0 11:09 ? 00:00:00 /usr/bin/dbus-daemon --syslog- only --fork --print-pid 5 --print-address myuser 26788 1 0 11:09 ? 00:00:00 /usr/bin/xconsole -file /dev/ xconsole -bg gainsboro -daemon -display loc myuser 26795 26792 0 11:09 ? 00:00:00 sshd: myuser@pts/1 myuser 26796 26795 0 11:09 pts/1 00:00:00 -bash
On 25.12.2022 16:38, mh@mike.franken.de wrote:
UID PID PPID C STIME TTY TIME CMD myuser 2352 1 0 Dez23 ? 00:00:03 /usr/bin/syncthing serve --no- browser --no-restart --logflags=0 myuser 2531 2352 0 Dez23 ? 00:17:30 /usr/bin/syncthing serve --no- browser --no-restart --logflags=0 myuser 10378 26796 0 14:36 pts/1 00:00:00 /bin/ps -fu myuser myuser 26670 1 0 11:09 ? 00:00:00 /usr/lib/systemd/systemd --user myuser 26671 26670 0 11:09 ? 00:00:00 (sd-pam) myuser 26676 26667 0 11:09 ? 00:00:00 sshd: myuser@notty myuser 26701 1 0 11:09 ? 00:00:00 dbus-launch --autolaunch 06de7a452f09bc3e8eb5225dc9fbee00 --binary-synta
What is output of env systemctl --user show-environment in ssh session?
myuser 26702 1 0 11:09 ? 00:00:00 /usr/bin/dbus-daemon --syslog- only --fork --print-pid 5 --print-address myuser 26788 1 0 11:09 ? 00:00:00 /usr/bin/xconsole -file /dev/ xconsole -bg gainsboro -daemon -display loc myuser 26795 26792 0 11:09 ? 00:00:00 sshd: myuser@pts/1 myuser 26796 26795 0 11:09 pts/1 00:00:00 -bash
On Sonntag, 25. Dezember 2022 14:46:50 CET Andrei Borzenkov wrote:
On 25.12.2022 16:38, mh@mike.franken.de wrote:
UID PID PPID C STIME TTY TIME CMD myuser 2352 1 0 Dez23 ? 00:00:03 /usr/bin/syncthing serve --no- browser --no-restart --logflags=0 myuser 2531 2352 0 Dez23 ? 00:17:30 /usr/bin/syncthing serve --no- browser --no-restart --logflags=0 myuser 10378 26796 0 14:36 pts/1 00:00:00 /bin/ps -fu myuser myuser 26670 1 0 11:09 ? 00:00:00 /usr/lib/systemd/systemd --user myuser 26671 26670 0 11:09 ? 00:00:00 (sd-pam) myuser 26676 26667 0 11:09 ? 00:00:00 sshd: myuser@notty myuser 26701 1 0 11:09 ? 00:00:00 dbus-launch --autolaunch 06de7a452f09bc3e8eb5225dc9fbee00 --binary-synta
What is output of
env systemctl --user show-environment
in ssh session?
My environment is huge and it contains lots of functions, but I'm not sure, why this is relevant, because the environment is much larger when reaching the command prompt. At the point, /etc/profile.d/openssh-dbus.sh is running, there are only about 20 variables. Wouldn't it be more interesting to see the env variables at this point?
myuser 26702 1 0 11:09 ? 00:00:00 /usr/bin/dbus-daemon --syslog- only --fork --print-pid 5 --print-address myuser 26788 1 0 11:09 ? 00:00:00 /usr/bin/xconsole -file /dev/ xconsole -bg gainsboro -daemon -display loc myuser 26795 26792 0 11:09 ? 00:00:00 sshd: myuser@pts/1 myuser 26796 26795 0 11:09 pts/1 00:00:00 -bash
On 25.12.2022 16:54, mh@mike.franken.de wrote:
On Sonntag, 25. Dezember 2022 14:46:50 CET Andrei Borzenkov wrote:
On 25.12.2022 16:38, mh@mike.franken.de wrote:
UID PID PPID C STIME TTY TIME CMD myuser 2352 1 0 Dez23 ? 00:00:03 /usr/bin/syncthing serve --no- browser --no-restart --logflags=0 myuser 2531 2352 0 Dez23 ? 00:17:30 /usr/bin/syncthing serve --no- browser --no-restart --logflags=0 myuser 10378 26796 0 14:36 pts/1 00:00:00 /bin/ps -fu myuser myuser 26670 1 0 11:09 ? 00:00:00 /usr/lib/systemd/systemd --user myuser 26671 26670 0 11:09 ? 00:00:00 (sd-pam) myuser 26676 26667 0 11:09 ? 00:00:00 sshd: myuser@notty myuser 26701 1 0 11:09 ? 00:00:00 dbus-launch --autolaunch 06de7a452f09bc3e8eb5225dc9fbee00 --binary-synta
What is output of
env systemctl --user show-environment
in ssh session?
My environment is huge and it contains lots of functions, but I'm not sure, why this is relevant, because the environment is much larger when reaching the command prompt. At the point, /etc/profile.d/openssh-dbus.sh is running, there are only about 20 variables. Wouldn't it be more interesting to see the env variables at this point?
show env | grep DBUS
myuser 26702 1 0 11:09 ? 00:00:00 /usr/bin/dbus-daemon --syslog- only --fork --print-pid 5 --print-address myuser 26788 1 0 11:09 ? 00:00:00 /usr/bin/xconsole -file /dev/ xconsole -bg gainsboro -daemon -display loc myuser 26795 26792 0 11:09 ? 00:00:00 sshd: myuser@pts/1 myuser 26796 26795 0 11:09 pts/1 00:00:00 -bash
On Sonntag, 25. Dezember 2022 15:11:05 CET Andrei Borzenkov wrote:
On 25.12.2022 16:54, mh@mike.franken.de wrote:
On Sonntag, 25. Dezember 2022 14:46:50 CET Andrei Borzenkov wrote: [...]
What is output of
env systemctl --user show-environment
in ssh session?
My environment is huge and it contains lots of functions, but I'm not sure, why this is relevant, because the environment is much larger when reaching the command prompt. At the point, /etc/profile.d/openssh-dbus.sh is running, there are only about 20 variables. Wouldn't it be more interesting to see the env variables at this point?
show
env | grep DBUS
myuser 26702 1 0 11:09 ? 00:00:00 /usr/bin/dbus-daemon --syslog- only --fork --print-pid 5 --print-address myuser 26788 1 0 11:09 ? 00:00:00 /usr/bin/xconsole -file /dev/ xconsole -bg gainsboro -daemon -display loc myuser 26795 26792 0 11:09 ? 00:00:00 sshd: myuser@pts/1 myuser 26796 26795 0 11:09 pts/1 00:00:00 -bash
empty
On 25.12.2022 17:16, mh@mike.franken.de wrote:
On Sonntag, 25. Dezember 2022 15:11:05 CET Andrei Borzenkov wrote:
On 25.12.2022 16:54, mh@mike.franken.de wrote:
On Sonntag, 25. Dezember 2022 14:46:50 CET Andrei Borzenkov wrote: [...]
What is output of
env systemctl --user show-environment
in ssh session?
My environment is huge and it contains lots of functions, but I'm not sure, why this is relevant, because the environment is much larger when reaching the command prompt. At the point, /etc/profile.d/openssh-dbus.sh is running, there are only about 20 variables. Wouldn't it be more interesting to see the env variables at this point?
Which is already what I asked you.
show
env | grep DBUS
myuser 26702 1 0 11:09 ? 00:00:00 /usr/bin/dbus-daemon --syslog- only --fork --print-pid 5 --print-address myuser 26788 1 0 11:09 ? 00:00:00 /usr/bin/xconsole -file /dev/ xconsole -bg gainsboro -daemon -display loc myuser 26795 26792 0 11:09 ? 00:00:00 sshd: myuser@pts/1 myuser 26796 26795 0 11:09 pts/1 00:00:00 -bash
empty
That should not be so. The only way I can reproduce your error is 1. There is already systemd user instance running (at least, /run/users/$UID/systemd exists) 2. There is no default session dbus socket (/run/users/$UID/bus) which is already something that should not happen - it is created automatically by systemd user instance. 3. sshd PAM configuration does not use pam_systemd 4. Something sets manually XDG_RUNTIME_DIR I have no idea how you can get into this situation. Check mentioned files/directories. As you refused to show environment, we also do not know whether XDG_RUNTIME_DIR is set and to which value.
On 12/25/22 11:11, Andrei Borzenkov wrote:
On 25.12.2022 17:16, mh@mike.franken.de wrote:
On Sonntag, 25. Dezember 2022 15:11:05 CET Andrei Borzenkov wrote:
On 25.12.2022 16:54, mh@mike.franken.de wrote:
On Sonntag, 25. Dezember 2022 14:46:50 CET Andrei Borzenkov wrote: [...]
What is output of
env systemctl --user show-environment
in ssh session?
My environment is huge and it contains lots of functions, but I'm not sure, why this is relevant, because the environment is much larger when reaching the command prompt. At the point, /etc/profile.d/openssh-dbus.sh is running, there are only about 20 variables. Wouldn't it be more interesting to see the env variables at this point?
Which is already what I asked you.
show
env | grep DBUS
myuser 26702 1 0 11:09 ? 00:00:00 /usr/bin/dbus-daemon --syslog- only --fork --print-pid 5 --print-address myuser 26788 1 0 11:09 ? 00:00:00 /usr/bin/xconsole -file /dev/ xconsole -bg gainsboro -daemon -display loc myuser 26795 26792 0 11:09 ? 00:00:00 sshd: myuser@pts/1 myuser 26796 26795 0 11:09 pts/1 00:00:00 -bash
empty
That should not be so.
The only way I can reproduce your error is
1. There is already systemd user instance running (at least, /run/users/$UID/systemd exists) 2. There is no default session dbus socket (/run/users/$UID/bus) which is already something that should not happen - it is created automatically by systemd user instance. 3. sshd PAM configuration does not use pam_systemd 4. Something sets manually XDG_RUNTIME_DIR
I have no idea how you can get into this situation. Check mentioned files/directories. As you refused to show environment, we also do not know whether XDG_RUNTIME_DIR is set and to which value.
This seems to come from spurious carriage returns generated by environment variables setting BASH_FUNC_* Firstly: Happens with ssh from Tumbleweed or Leap 15.4 to Leap 15.4 Affects only bash, tcsh does not show this error. This error depends on which packages are installed Setting verbose in /etc/profile.d/openssh-dbus.sh shows variables that are set, but that are on two lines (the last line being a single closing brace "}"), so this single character is probably being attempted to be set as an environment variable (which does not work). The variables being set on my instance are: BASH_FUNC_module%%, BASH_FUNC_mc%%, and BASH_FUNC_ml%%. These are the only variables with the BASH_FUNC_ prefix. Removing these packages (Lmod and MC: 'zypper remove lua-lmod mc') eliminates the error. I have not found the source that is setting the variables, but I imagine that since there is already an open case, it will be found and corrected. -- Patrick McNeil Université de Montréal - TI Pav. Roger-Gaudry, Y-201-11b ☎ Téléphone: (514) 343-6111, poste 5247 📧 Courriel: patrick.mcneil@umontreal.ca 📠 Télécopie/FAX: (514) 343-2155
On Sonntag, 25. Dezember 2022 17:15:01 CET Patrick McNeil wrote: [...]
This seems to come from spurious carriage returns generated by environment variables setting BASH_FUNC_* Firstly: Happens with ssh from Tumbleweed or Leap 15.4 to Leap 15.4 Affects only bash, tcsh does not show this error. This error depends on which packages are installed
It also happens from Fedora or Windows systems to a Leap 15.4 system.
Setting verbose in /etc/profile.d/openssh-dbus.sh shows variables that are set, but that are on two lines (the last line being a single closing brace "}"), so this single character is probably being attempted to be set as an environment variable (which does not work).
No, not here. I get the message from the subject for every variable. As I wrote in a former message, I replaced the --all with a few lines setting one variable at a time, and I get the message for every line.
The variables being set on my instance are: BASH_FUNC_module%%, BASH_FUNC_mc%%, and BASH_FUNC_ml%%. These are the only variables with the BASH_FUNC_ prefix. Removing these packages (Lmod and MC: 'zypper remove lua-lmod mc') eliminates the error. I have not found the source that is setting the variables, but I imagine that since there is already an open case, it will be found and corrected.
These variables don't exist at the point, /etc/profile.d/openssh-dbus.sh is called. At this point only about 20 variables exist - and none of them contains special characters.
On Sonntag, 25. Dezember 2022 17:11:07 CET Andrei Borzenkov wrote:
On 25.12.2022 17:16, mh@mike.franken.de wrote:
On Sonntag, 25. Dezember 2022 15:11:05 CET Andrei Borzenkov wrote:
On 25.12.2022 16:54, mh@mike.franken.de wrote:
On Sonntag, 25. Dezember 2022 14:46:50 CET Andrei Borzenkov wrote: [...]
What is output of
env systemctl --user show-environment
in ssh session?
My environment is huge and it contains lots of functions, but I'm not sure, why this is relevant, because the environment is much larger when reaching the command prompt. At the point, /etc/profile.d/openssh-dbus.sh is running, there are only about 20 variables. Wouldn't it be more interesting to see the env variables at this point?
Which is already what I asked you.
Uhm, then I misunderstood you or I didn't find the correct wording. I meant the env vars that /etc/profile.d/openssh-dbus.sh is seeing.
show
env | grep DBUS
myuser 26702 1 0 11:09 ? 00:00:00 /usr/bin/dbus-daemon --syslog- only --fork --print-pid 5 --print-address myuser 26788 1 0 11:09 ? 00:00:00 /usr/bin/xconsole -file /dev/ xconsole -bg gainsboro -daemon -display loc myuser 26795 26792 0 11:09 ? 00:00:00 sshd: myuser@pts/1 myuser 26796 26795 0 11:09 pts/1 00:00:00 -bash
empty
That should not be so.
The only way I can reproduce your error is
1. There is already systemd user instance running (at least, /run/users/$UID/systemd exists)
exists
2. There is no default session dbus socket (/run/users/$UID/bus) which is already something that should not happen - it is created automatically by systemd user instance.
doesn't exist
3. sshd PAM configuration does not use pam_systemd
how can I check this?
4. Something sets manually XDG_RUNTIME_DIR
I have no idea how you can get into this situation. Check mentioned files/directories. As you refused to show environment, we also do not know whether XDG_RUNTIME_DIR is set and to which value.
echo $XDG_RUNTIME_DIR /run/user/10000
On 25.12.2022 19:23, mh@mike.franken.de wrote:
The only way I can reproduce your error is
1. There is already systemd user instance running (at least, /run/users/$UID/systemd exists)
exists
2. There is no default session dbus socket (/run/users/$UID/bus) which is already something that should not happen - it is created automatically by systemd user instance.
doesn't exist
That is enough to reproduce the problem. So this is the main reason. Did you try to reboot your server? Do you still observe the problem after reboot?
3. sshd PAM configuration does not use pam_systemd
how can I check this?
It is red herring, the root cause is the missing D-Bus socket.
4. Something sets manually XDG_RUNTIME_DIR
I have no idea how you can get into this situation. Check mentioned files/directories. As you refused to show environment, we also do not know whether XDG_RUNTIME_DIR is set and to which value.
echo $XDG_RUNTIME_DIR /run/user/10000
On Sonntag, 25. Dezember 2022 19:57:48 CET Andrei Borzenkov wrote: [...]
2. There is no default session dbus socket (/run/users/$UID/bus) which is already something that should not happen - it is created automatically by systemd user instance.
doesn't exist
That is enough to reproduce the problem. So this is the main reason. Did you try to reboot your server? Do you still observe the problem after reboot?
yep
On Sonntag, 25. Dezember 2022 20:17:04 CET mh@mike.franken.de wrote:
On Sonntag, 25. Dezember 2022 19:57:48 CET Andrei Borzenkov wrote: [...]
2. There is no default session dbus socket (/run/users/$UID/bus) which is already something that should not happen - it is created automatically by systemd user instance.
doesn't exist
That is enough to reproduce the problem. So this is the main reason. Did you try to reboot your server? Do you still observe the problem after reboot?
yep
I updated two more machines with the latest hotfixes. One of them shows the same error message, the other on doesn't. Both are Leap 5.4, too.
On 25.12.2022 22:45, mh@mike.franken.de wrote:
On Sonntag, 25. Dezember 2022 20:17:04 CET mh@mike.franken.de wrote:
On Sonntag, 25. Dezember 2022 19:57:48 CET Andrei Borzenkov wrote: [...]
2. There is no default session dbus socket (/run/users/$UID/bus) which is already something that should not happen - it is created automatically by systemd user instance.
doesn't exist
That is enough to reproduce the problem. So this is the main reason. Did you try to reboot your server? Do you still observe the problem after reboot?
yep
I updated two more machines with the latest hotfixes. One of them shows the same error message, the other on doesn't. Both are Leap 5.4, too.
Patch has nothing to do with it, it is just the messenger. Try to find out when D-Bus socket disappears. Reboot, log in on local console. Is systemd user instance active? Is file /run/users/$UID/bus present? Log over SSH. Is file present or disappeared? etc ...
On Montag, 26. Dezember 2022 06:59:34 CET Andrei Borzenkov wrote:
On 25.12.2022 22:45, mh@mike.franken.de wrote:
On Sonntag, 25. Dezember 2022 20:17:04 CET mh@mike.franken.de wrote:
On Sonntag, 25. Dezember 2022 19:57:48 CET Andrei Borzenkov wrote: [...]
2. There is no default session dbus socket (/run/users/$UID/bus) which is already something that should not happen - it is created automatically by systemd user instance.
doesn't exist
That is enough to reproduce the problem. So this is the main reason. Did you try to reboot your server? Do you still observe the problem after reboot?
yep
I updated two more machines with the latest hotfixes. One of them shows the same error message, the other on doesn't. Both are Leap 5.4, too.
Patch has nothing to do with it, it is just the messenger.
But it started with the new hotfixes, because openssh- server-8.4p1-150300.3.15.4.x86_64 contains /etc/profile.d/openssh-dbus.sh for the first time. That's what I meant.
Try to find out when D-Bus socket disappears. Reboot, log in on local console. Is systemd user instance active? Is file /run/users/$UID/bus present? Log over SSH. Is file present or disappeared? etc ...
This is not possible at the moment, because the server is 700 km away. I'll try when we will be back home. Thx!
participants (5)
-
Andrei Borzenkov -
Lew Wolfgang -
Mark Gray -
mh＠mike.franken.de -
Patrick McNeil