I suspend my workstation in night, and inform users (a few including
myself) by invoking 'wall' with a Warning message a few minutes before
the workstation Sleeps at a particular time in the night. However,
after upgrading to Trixie, it does not beep the terminals or send any
message to users.
As notified, there is no 'utmp' support by default, and probably 'wall'
does not get the list of users logged in.
Therefore, I installed 'wtmpdb' package, and 'last' is linked to
'wtmpdb'. Invoking 'last' works.
However, I still find 'wall File_name' invoked as root still produces
no response to me in a different Terminal (logged in through 'ssh').
Therefore, I consider this as a bug.
As 'wall' stops working, it significantly increases the problem of Root
to notify users of any issues or impending System Shutdown immediately.
Therefore, it needs to be fixed.
Please note that 'wall' works fine from my other system running
'bookworm'.

wall is built with systemd/logind support, the modern replacement
for utmp.

Make sure your sessions are listed in `loginctl` output (with a
TTY). If they are not, make sure you have libpam-systemd installed
and systemd-logind is running.

There might still be an issue with openssh not forwarding the TTY to
logind; if you are affected by this, then `wall` cannot do anything
about this. Best to test with a local login.

systemd also has an internal `wall` implementation, used to warn
users of impending shutdowns (and I suspect suspends).

I'll wait a bit for you to show that it's really `wall` that is the
problem here, and not something else; otherwise I'll close this
report.

Best,
Chris

Would you mind outlining how this systemd/logind support in
/usr/bin/wall can be demonstrated to be working, and how to use
systemd's internal wall implementation? How to send, how to receive?

I checked for both the possible issues as you have mentioned. I do have 'libpam-systemd' installed. Also, 'systemd-logind' is running. However, still 'wall' did not echo anything on screen, as shown in the screenshot attached.I could hear the sound of system-bell (pcspkr) locally, once the command was entered.
BTW, I am using 'xterm' as the terminal for local display.

I also have the same issue, and also have libpam-systemd installed and systemd-logind running.

When I do a wall command from a xfce session, no terminals in that session or logins via ssh get the wall output, but a login on virtual console via ctrl-alt-f1 does get the output.

With the virtual console active, loginctl shows a "tty1" session under the TTY column, but all other sessions under the TTY column have a "-", which appears to be the same as the attached image in message #20.

Is this then a loginctl/systemd related issue?

Best regards
Paul

FYI, I had already reported this issue in 2024:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1087642

but the bug was closed without any solution.

Note that there is the same issue with systemd's shutdown command:

https://github.com/systemd/systemd/issues/35246

If "wall" expects the terminal to be part of the loginctl output,
then unfortunately, no login sessions have an attached TTY in my
case. But anyway, all terminals should normally be listed because
the goal is that the user should have the information at least in
the terminal he/she is watching. So I suppose that bugs should be
reported against these terminals (as this is where utmp was
handled).

Hi,

On Fri, 16 Jan 2026 00:52:06 +0100 Vincent Lefevre <vincent@vinc17.net> wrote:
logind. So all sessions that do not have a TTY in logind will not get
notified by "wall."

Logind gets the TTY from the PAM_TTY attribute. SSH does not set the TTY
while executing the PAM session hooks because it allocates the TTY
later, and may not have to allocate a TTY at all. So SSH sets PAM_TTY to
"ssh", and logind ignores the TTY if it is set to "ssh".

What confused me was that logind on Bookworm does show the TTY
information for SSH connections. It turns out that on Bookworm, logind
is using the TTY information from UTMP. However, UTMP was removed in Trixie.

So we need another way to set the TTY for the logind session to make
"wall" work again.

Thanks,
Alex

This is not true. With the re-creation of /run/utmp by
libutempter0 1.2.1-5, the xterm windows get the wall message.

Anyway, not all terminals run ssh.

If I understand correctly, /run/utmp was created by some systemd
package, and this is no longer done:

  systemd (256.7-2) unstable; urgency=medium
[...]
  * Disable utmp support, not y2038 safe. utmp support in tmux has been
    disabled, so autopkgtest should no longer break

But since it is still used by libutempter (and the terminals that
use this library), it is now recreated there:

/usr/lib/tmpfiles.d/libutempter0.conf contains

f /run/utmp 0664 root utmp

But since utmp support is currently not y2038 safe, there are
3 solutions until 2038 comes:

1. Make utmp y2038 safe (e.g. by changing the timestamp to 64 bits,
   which would need to rebuild the few programs that still use it).

2. Ignore the time in utmp (it doesn't seem to be used any longer,
   since "who" and "w" no longer use utmp).

3. Entirely replace utmp by logind for plain text terminals, e.g.
   started from the window manager or from other applications
   (PAM is not involved, so there should be some documentation
   on what to do).

Currently, there is no logind session for plain text terminals.