# "Failed to connect to system scope bus" on reboot/poweroff
**URL:** https://dietpi.com/forum/t/failed-to-connect-to-system-scope-bus-on-reboot-poweroff/25413
**Category:** General Discussion
**Created:** [14 August 2026 21:18 UTC](https://dietpi.com/forum/t/failed-to-connect-to-system-scope-bus-on-reboot-poweroff/25413 "2026-08-14T21:18:00Z")
**Posts on this page:** 5
**Page:** 1
### Author:  [@CA\_Lobo](https://dietpi.com/forum/u/CA_Lobo)
#### Post date: [14 August 2026 21:18 UTC](https://dietpi.com/forum/t/failed-to-connect-to-system-scope-bus-on-reboot-poweroff/25413/1 "2026-08-14T21:18:00Z")
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.
---
### Author:  [@MichaIng](https://dietpi.com/forum/u/MichaIng)
#### Post date: [14 August 2026 23:06 UTC](https://dietpi.com/forum/t/failed-to-connect-to-system-scope-bus-on-reboot-poweroff/25413/2 "2026-08-14T23:06:44Z")
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](https://github.com/MichaIng/DietPi/commit/e16d15a)
But this is entirely unrelated to the Orange Pi Zero image conversion topic 😄.
_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)._
---
### Author:  [@CA\_Lobo](https://dietpi.com/forum/u/CA_Lobo)
#### Post date: [15 August 2026 05:35 UTC](https://dietpi.com/forum/t/failed-to-connect-to-system-scope-bus-on-reboot-poweroff/25413/3 "2026-08-15T05:35:09Z")
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… 🙂
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…
```bash
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. 🙂
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.
---
### Author:  [@MichaIng](https://dietpi.com/forum/u/MichaIng)
#### Post date: [15 August 2026 11:11 UTC](https://dietpi.com/forum/t/failed-to-connect-to-system-scope-bus-on-reboot-poweroff/25413/4 "2026-08-15T11:11:10Z")
I split this into a new topic. Generally, this error
```auto
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 🙂.
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:
```auto
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 `reboot`s/`poweroff`s, 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 `sync`ed 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`
> [@CA\_Lobo](#):
>
> So unless dietpi-banner will be run under sudo, it’s unlikely the changes will work.
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`.
---
### Author:  [@CA\_Lobo](https://dietpi.com/forum/u/CA_Lobo)
#### Post date: [16 August 2026 18:48 UTC](https://dietpi.com/forum/t/failed-to-connect-to-system-scope-bus-on-reboot-poweroff/25413/5 "2026-08-16T18:48:17Z")
Glad to know that I got some brain cells thinking about passing shell functions to sudo reboot… 🙂
Thanks for the info on the negative impact of -n option on reboot… I’ll stop using it as I had no idea that this option could cause problems…
I look forward to seeing the fixed version of dietpi-banner in an upcoming release.
Bottom line, thanks for taking the time to educate a linux newbie on the more minute details - it is much appreciated, as is your efforts to continue to improve dietpi.