Errors when doing a reboot

[zordaz]

Creating a bug report/issue

• [X] I have searched the existing open and closed issues

Required Information

• DietPi version: v9.6.13
• Distro version: trixie 0
• Kernel version: Linux DietPi 6.12.47+rpt-rpi-v8 # 1 SMP PREEMPT Debian 1:6.12.47-1+rpt1 (2025-09-16) aarch64 GNU/Linux
• SBC model: RPi 3 Model B (aarch64)
• Power supply used: unknown
• SD card used: 16GB Transcend

Additional Information (if applicable)

N/A

Steps to reproduce

Reboot the RPI with one of the following commands.

Expected behaviour

The system should reboot without error messages, instead it should give a proper 'rebooting' alike message. It might be a cosmetic error, but IMO it should be solved anyway.

Actual behaviour

When doing a reboot via 'shutdown -r now' or 'poweroff --reboot' or 'systemctl reboot' only an ugly error is shown before the SSH connection is lost (partly in Dutch due to my systems locale):

Failed to connect to system scope bus via local transport: Bestand of map bestaat niet Failed to connect to system scope bus via local transport: Bestand of map bestaat niet

Extra details

[MichaIng]

systemd is probing for scheduled shutdown, sending out wall messages (so people can save their stuff before shutdown), and checking for shutdown inhibitors, a bunch of things which make sense on systems used by multiple people in parallel. This requires systemd-logind and communication is done via DBus.

Since these are irrelevant features for the vast majority of server systems, DietPi images ship with systemd-logind masked and DBus not pre-installed. A normal shutdown is done even if those logind calls fail, so it is visual only.

Since systemd 252 these Dbus > logind calls are always done and fail loudly, even if you explicitly do immediate shutdown/reboot and explicitly declare not to send a wall message (which is kinda nonsense anyway for immediate actions). If you are interested in some more details: https://github.com/systemd/systemd/issues/28902

To work around the noisy messages, if systemd-logind is masked, our login script creates shell functions to replace reboot, poweroff, and halt commands with their respective systemctl start <command>.target calls. These targets trigger a regular shutdown, are used by the reboot/systemctl reboot/shutdown/halt/poweroff -r/--reboot calls as well, but after the logind calls.

We do not create systemctl <command> or shutdown alias:

• systemctl reboot and reboot are the same, same with poweroff and halt.
• shutdown is not really meant for immediate actions, but for scheduled ones. poweroff is the one meant for immediate action. Of course they are internally all the same, just pass through different default options to systemd.

If you see the error for when doing poweroff --reboot, then our function does not seem to be used. Do you use a different shell, like fish or zsh instead of bash? Or is systemd-logind unmasked, while DBus is not running?

systemctl status systemd-logind

[zordaz]

It's a fresh DietPi/Trixie install with an absolute minimum of adjustments (mainly a fixed IP, SSH instead of dropbear, docker-ce, all done via dietpi-software), so no different shell is being used. My former Bookworm installation also gave (different) errors when doing a 'shutdown -r now'.

sudo systemctl status systemd-logind
○ systemd-logind.service
     Loaded: masked (Reason: Unit systemd-logind.service is masked.)
    Drop-In: /usr/lib/systemd/system/systemd-logind.service.d
             └─dbus.conf
     Active: inactive (dead)

I haven't touched the systemd config at all.

[MichaIng]

Can you show this:

declare -f poweroff

[zordaz]

declare -f poweroff
poweroff () 
{ 
    local command='poweroff';
    for i in "$@";
    do
        case $i in 
            '-p' | '--poweroff' | '--no-wall')
                :
            ;;
            '--reboot')
                command='reboot'
            ;;
            '--halt')
                command='halt'
            ;;
            *)
                /sbin/poweroff "$@";
                return $?
            ;;
        esac;
    done;
    systemctl start "$command.target"
}

[MichaIng]

And

poweroff --reboot

without any other argument throws these errors?

[zordaz]

• The command without sudo gives the error once, but the system doesn't reboot.
• When invoking the command with sudo the error is given twice (as noted above) and the system reboots. The SSH connection hangs and is terminated by pressing 'enter'.

[MichaIng]

The command without sudo gives the error once, but the system doesn't reboot.

When doing this as root or non-root user?

When you use sudo, indeed the functions are not used, since the environment (variables and functions) is not passed through sudo (by default). But that the error is shown twice in that case is unexpected. Maybe you have polkid installed which is invoked first or so:

dpkg -l polkitd

That one however forcefully pulls DBus as dependency.

[zordaz]

When doing this as root or non-root user?

As a non-root user.

In the meantime I've tested it as root as well and then the system reboots without the error. polkitd isn't installed.

[MichaIng]

Now I see it. Only in a login shell, systemd seems to try getting the needed privileges, maybe from polkitd (regardless whether installed or not), but as well via DBus.

A bit annoying that there is no way to configure it skipping DBus calls in general. I wished it would be a lot more modular with all those additional features optional. But Lennart made clear that for him this is all needed. I mean makes sense, this opinion reflected in systemd design/development in general is the major point of criticism from the Linux community, and why there is, despite the obvious benefits, still a strong core of people who consequently avoid systemd and use classic SysV or other simpler (in design, not usage) init systems.

So as you can see, those errors are visual only, and regular reboot/shutdown works just fine with root permissions, as expected.

If this annoys you for some reason, to get rid of them, you need logind and DBus:

systemctl unmask systemd-logind
apt install dbus
systemctl start dbus systemd-logind

After this, systemd can do all the stuff it tries to do via DBus and logind before performing the shutdown/reboot, hence won't throw these errors anymore.

[zordaz]

Tnx for the analysis. Installing DBus will bring some other related packages as well. Not much, but I'll think about it.

This indeed is one of the side effects of systemd. My opinion about systemd is nuanced, but the part I am not fond of is the trawl of dependencies it brings on system/OS level, which makes troubleshooting much more time consuming and complicated than it once was. What also irritates me is the horrible state of the error messages that are thrown to end-users.

[MichaIng]

Jep I agree to both: Debian already splits parts of systemd into dedicated packages which are usually all built together, but these unconditional DBus/logind calls for these very basic commands show well how limited the possibilities are, and how much several components are increasingly tied together, which could be all made optional by design.

And more components involved means more points of failures and more levels at which logs can be emitted. Like here:

• Dbus must be installled and active, else it always throws an error that it is missing, not saying for what it is called in the first place.
• logind must be active, else DBus throws an error that it is not there, AFAIK then saying as well that it was called for wall measages.
• When disabling wall messages via CLI the error does not change, since the CLI option does not prevent the logind call, but just tells logind to not send the wall message, while the call is done for at least shutdown inhibitors as well, which is however not shown. So error is irritating when actively disabling wall messages.
• Knowing what's wrong and why is rather difficult and unexpected for such a basic command.