"Failed to connect to system scope bus" on reboot/poweroff

General Discussion
1

Not sure if it’s relevant, but I’ve noticed that version <10.6, same message "Failed to connect to system scope bus via local transport: No such file or directory" appeared twice on a Zero 3 without the extra ports hat during reboot. While I previously ignored the errors during reboots, the issue is more visible with new 10.6 dietpi-banner option to display systemd status, and results in:

systemd status : Failed to connect to system scope bus via local transport: No such file or directory
No services failed

If I understand things correctly, the issue is that systemd attempts to initialize the missing ports and fails gracefully with a benign error… and then gracefully fails again when attempting to tear down the missing ports during a reboot.

My only concerned is that it will cause confusion… and like me, drive people to the forum to figure out if the error message is critical or not. I would hope that there is someway to check for the existence of the extra port hat, and if so, only initialize the available ports vs attempting to blindly initialize them and fail gracefully, while leaving bogus error messages behind.

2

Oh that makes sense. non-root users cannot call systemctl without D-Bus. So we need to either check whether D-Bus is active, otherwise use sudo, or use sudo directly, as non-root user.

Fixed with: dietpi-banner: some fixes · MichaIng/DietPi@e16d15a · GitHub

But this is entirely unrelated to the Orange Pi Zero image conversion topic :smile:.

If you see this error when running reboot, either you call sudo reboot, or logind is not active, but not masked. If it is masked, we add shell functions for reboot, poweroff, and halt, which bypass the dbus>logind calls (needed only for wall messages and shutdown inhibitors, but done even if none of this is used).

3

Re: Non root users need to use sudo for systemctl - yep, it bites me occasionally when I forget to sudo… along with the journalctl command. ‘sudo !!’ has become my new friend… :slight_smile:

I looked at your changes, and not being a bash expert, I can’t tell if the dietpi-banner changes will be run under sudo or not. I took the commands from the your bash script and ran them on my Orange Pi Zero 3 without an extra ports top hat and a basic install - eg no D-Bus - to see what they would do…

dietpi@pihole:~$ systemctl --failed
Failed to connect to system scope bus via local transport: No such file or directory
dietpi@pihole:~$ sudo systemctl --failed
  UNIT LOAD ACTIVE SUB DESCRIPTION

0 loaded units listed.
dietpi@pihole:~$ systemctl --failed --no-legend --no-pager
Failed to connect to system scope bus via local transport: No such file or directory
dietpi@pihole:~$ sudo systemctl --failed --no-legend --no-pager
dietpi@pihole:~$ sudo reboot -n
Failed to connect to system scope bus via local transport: No such file or directory
Failed to connect to system scope bus via local transport: No such file or directory
Connection to 192.168.20.2 closed by remote host.
Connection to 192.168.20.2 closed.

So unless dietpi-banner will be run under sudo, it’s unlikely the changes will work. To test the theory, I did run sudo dietpi-banner 1 and it reported:

- systemd status : No services failed

So it does look like something needs to be run under sudo to get the correct results for systemd status…

My apologize for not knowing that this was an Orange Pi Zero image conversion… the error message was the same and reading through the report made it seem like it was the same issue. :slight_smile:

As for the last paragraph, it’s way beyond my minimal linux knowledge… but see above for the output from the sudo reboot -n command and the errors reported… looks like it’s trying to tear down non existing ports… and I’m already running under sudo…

Let me know if I can be of further help.

4

I split this into a new topic. Generally, this error

Failed to connect to system scope bus via local transport

just tells you that the executed command tried to access D-Bus, while it was not active. Whether this is an actual issue depends on what did the D-Bus call for which reason.

1. sudo reboot

Here the error is expected, if either D-Bus or logind are not active. We add shell functions to prevent them for direct reboot/poweroff/halt calls, but shell functions are not passed through sudo. I am actually just thinking about a method to achieve that :slightly_smiling_face:.

Anyway, this is purely visual, without any actual impact on the reboot/poweroff behavior. The D-Bus > logind calls are relevant only on systems used interactively by multiple real people, so that the admin might want to schedule a timed shutdown, like in 5 minutes, meanwhile showing a wall message to logged in users about that:

shutdown +5 'Shutting down in 5 minutes guys, save your stuff!'

, so they can save their changes, or can set a shutdown inhibitor, to prevent or delay the shutdown (if they have permissions for that). For a typical SBC use case, where you’re just doing immediate reboots/poweroffs, none of this is relevant.

What however really has a negative impact on our particular reboot call is the -n option: This prevents hard drive writes from being synced to disk at shutdown. That way, any changes still in write buffer will be lost. You shouldn’t use this option without very good reasons, like some kind of emergency.

2. dietpi-banner

The change wraps the systemctl --failed call in sudo, if called by a non-root user, and if D-Bus is not active. With an active D-Bus daemon or socket, non-root users can call systemctl without requiring sudo.