Wall / Mesg - Blank reboot message/SSH hangs on reboot (doenst disconnect cleanly)

[henryjfry]

Im aware of:

Warning during reboot

And on the newest DietPi my SSH session would just stop until it eventually decided it couldnt connect anymore on reboot (which is very annoying).

Having fixed this before i reinstalled:

sudo apt-get install libpam-systemd dbus

And did the steps

sudo systemctl unmask systemd-logind
sudo systemctl start systemd-logind

sudo systemctl enable dbus
sudo systemctl start dbus

And also:

sudo nano /etc/systemd/system/ssh-user-sessions.service

[Unit]
Description=Shutdown all ssh sessions before network
After=network.target

[Service]
TimeoutStartSec=0
Type=oneshot
RemainAfterExit=yes
ExecStart=/bin/true
ExecStop=/usr/bin/killall sshd

[Install]
WantedBy=multi-user.target

Which seems to fix the SSH session just hanging and not disconnecting on reboot.

But no matter what I do i cant get a message to say

“The system is going down for system reboot NOW!”

Why is this disabled in dietpi and how can i fix it properly?

[Joulinar]

@henryjfry

But no matter what I do i cant get a message to say

“The system is going down for system reboot NOW!”

did you tried

sudo shutdown -r +1 "Rebooting in 1 minute for maintenance"

[henryjfry]

Yes but why doesnt “sudo reboot” just do what its supposed to?

And given that it doenst how do i fix it?

echo “hello world” | sudo wall

Doesnt display any messages so manually fixing the “reboot” alias doesnt fix anything

I dont understand why dietpi now out of the box deliberately changes default behaviour so that the message is suppressed and the ssh session doesnt disconnect

[Joulinar]

@henryjfry

and the ssh session doesnt disconnect

for me SSH is disconnecting always on all my systems. Never have seen a report on this before

@henryjfry

I dont understand why dietpi now out of the box deliberately changes default behaviour

reboot command itself does not send a wall message best to my knowledge. Only shutdown can do this

[Jappe]

@henryjfry

I dont understand why dietpi now out of the box deliberately changes default behaviour so that the message is suppressed and the ssh session doesnt disconnect

It’s the diet part of DietPi, so ttys, dbus and systemd-logind are disabled.

But I don’t get the ssh and reboot part, on my system I also get a disconnect when it loses SSH connection.
What SSH server and client do you use?

For testing I did:

apt-get install -y libpam-systemd dbus
systemctl unmask systemd-logind
systemctl enable systemd-logind
systemctl start systemd-logind
systemctl status systemd-logind
systemctl enable dbus
systemctl start dbus
echo "Hello world" | sudo wall

And got no message, because /run/utmp is still missing.
So I did:

touch /run/utmp
chmod 664 /run/utmp
chown root:utmp /run/utmp

And now it’s working.

And this will only work with systemctl, reboot does not send a message.
But you could set an alias for reboot, to use systemctl under the hood.

[henryjfry]

The SSH sessions and SFTP sessions eventually disconnect themselves, but they dont get the “exit”/“The system is going down for system reboot NOW!” message so dont exit cleanly.

I dont want my ssh session to stall until it decides it can disconnect. Particularly when there is a linux process which should be implemented to disconnect and save bash_local and whatever else happens when a clean reboot is performed.

Im not sure why the devs of dietpi thought disabling the thing which kills active connections when someone requests a reboot was a good idea.

But not killing active SSH connections on reboot is absolutely a bug.

The missing wall message is just annoying.

[henryjfry]

@Jappe

systemctl enable dbus
systemctl start dbus

I’ve got a clean SSH disconnect now but no wall.

I can see a wall message and I should have already aliased reboot but its not working:

\home\dietpi\.bashrc

alias reboot='echo "The system is going down for system reboot NOW!" | sudo wall ; /usr/bin/sudo /bin/systemctl --force reboot'

alias poweroff='echo "The system is going down for system halt NOW!" | sudo wall  ; /usr/bin/sudo /bin/systemctl --force poweroff'

alias seems to be preempted?

[Joulinar]

If you want the message always sent, even when someone just runs reboot, you can use a systemd pre-reboot-message service:

sudo nano /etc/systemd/system/pre-reboot-message.service

add

[Unit]
Description=Broadcast message before reboot
Before=reboot.target
DefaultDependencies=no

[Service]
Type=oneshot
ExecStart=/usr/bin/wall "🔁 System is rebooting now. Please save your work."

[Install]
WantedBy=reboot.target

and do

sudo systemctl enable pre-reboot-message.service

This ensures any reboot — whether from reboot, shutdown -r, or systemctl reboot — will show a message first.

[henryjfry]

Ok thats cool but ive just actually tried:

/bin/systemctl --force reboot

And got no wall message either.

So it appears this is not persistent:

sudo touch /run/utmp
sudo chown root:utmp /run/utmp
sudo chmod 664 /run/utmp

And the rule to create it doesnt exist.

sudo tee /etc/tmpfiles.d/utmp.conf >/dev/null <<'EOF'
f /run/utmp 0664 root utmp -
EOF

sudo systemd-tmpfiles --create

[henryjfry]

But it still doesnt load the wall when i:

sudo /bin/systemctl --force reboot

Like you kind of need to know if you get booted off the network that there is a reason?

I dont understand the rationalle for disabling this message and not having a config option to re-enable it for multi user environments.
(and graceful exit, which is the important part)

[Joulinar]

Hmm working for me

client 1 submitting shutdown -r

root@DietPi5:~# shutdown -r
Reboot scheduled for Tue 2025-10-07 22:08:13 CEST, use 'shutdown -c' to cancel.
root@DietPi5:~#

client 2 receiving the message

root@DietPi5:~#
Broadcast message from root@DietPi5 on pts/0 (Tue 2025-10-07 22:07:13 CEST):

The system will reboot at Tue 2025-10-07 22:08:13 CEST!


root@DietPi5:~#

you would need to do following beforhand

@Jappe

apt-get install -y libpam-systemd dbus
systemctl unmask systemd-logind
systemctl enable systemd-logind
systemctl start systemd-logind
systemctl status systemd-logind
systemctl enable dbus
systemctl start dbus

[henryjfry]

@Joulinar

shutdown -r

Having:

apt-get install -y libpam-systemd dbus
systemctl unmask systemd-logind
systemctl enable systemd-logind
systemctl start systemd-logind
systemctl status systemd-logind
systemctl enable dbus
systemctl start dbus

Fresh install that did send the message but its not gracefully disconnecting the ssh/sftp session hangs/timesout.

[henryjfry]

This does the job from a fresh install:

openSSH

apt-get install -y libpam-systemd dbus
systemctl unmask systemd-logind
systemctl enable systemd-logind
systemctl start systemd-logind
systemctl status systemd-logind
systemctl enable dbus
systemctl start dbus

Then creating a user reboot which calls “/bin/systemctl --force reboot” actuall disconnects the shell sessions while the dietpi reboot doesnt.

sudo nano /usr/local/bin/reboot
sudo chmod +x /usr/local/bin/reboot

#!/bin/bash

sudo touch /run/utmp
sudo chown root:utmp /run/utmp
sudo chmod 664 /run/utmp
echo "The system is going down for system reboot NOW!" | sudo wall
/bin/systemctl --force reboot