Today, for reasons outside the scope of this entry, we needed to do unscheduled reboots on a number of Ubuntu 26.04 servers that people log in to and use. As is our usual process, we didn't reboot these on the spot; instead we ran ' shutdown -r +NN "<a message about the situation>" ' so that people would have a little bit of warning because the impending shutdown would be periodically announced ( by systemd, because this is systemd-based these days ). Then, to our unpleasant surprise, we discovered that no announcements were happening. Shortly afterward we discovered that the venerable ' wall ' program wasn't making announcements either.

Surprisingly, these turn out to be two separate issues. The wall issue is because starting in Debian 13 ('Trixie') and Ubuntu 25.10, the Debian and Ubuntu systemd is built without support for /var/run/utmp (aka /run/utmp), the traditional file recording who is logged in where; wall (which comes from the 'bsdutils' package) only looks in the utmp file. If there's no utmp file, wall is never going to do anything. If you need a wall equivalent, you'll need to write a script that gets the list of active user sessions with ptys and writes a message to them itself.

(For Debian Trixie dropping support for utmp, see eg this debian-devel thread . Apparently one reason for the change is that the utmp format has Y2038 problems . A replacement is available through the wtmpdb package and project, which also gives you a working ' last ' command. You have to hook it up in your PAM configuration, and the Ubuntu 26.04 OpenSSH is built without wtmpdb support, so I believe you're going to be missing some information.)

The issue with shutdown not broadcasting messages appears to be because in Ubuntu 26.04 (with systemd 259.5), systemd's logind doesn't know what ttys people's SSH logins are using. You can see this with ' loginctl ' or ' loginctl -j ', which will have no TTY information for all SSH logins (although if you log in on the console, it will have that). This isn't the case in Ubuntu 24.04 (with systemd 255.4) or Fedora 43 (with systemd 258.9), although both versions are built with UTMP support (in theory this shouldn't matter, since logind's tty tracking is a separate thing). Logind's announcements of impending shutdowns only go to TTYs that it knows about, so since it doesn't know about any SSH login ptys, none of them get any announcements.

If you're using 'who' or 'w' on Ubuntu 26.04 (or at least the version of 'who' from GNU Coreutils , since the uutils version currently suffers from bug #2152801 ), you might notice that they do report pty information, at least if you have AppArmor disabled ( as we do ):

; who
cks      sshd pts/0   Jul 20 21:47 (...)
; lsb_release -r
Release:        26.04

This is because while the GNU Coreutils version of 'who' talks to systemd to try to get this information (through a set of systemd library APIs), if there's no TTY information for a session it will also look through /dev/pts to try to find a likely candidate . This works often enough that 'who' typically shows information for most interactive SSH sessions with a pty. The ' w ' program, which comes from procps, has a similar fallback if systemd and utmp are both not reporting the tty . Since ' who ' and ' w ' use different approaches, on Ubuntu 26.04 one may report a tty that the other doesn't.

(Apparently the default Ubuntu 26.04 AppArmor profiles block access by ' who ' to /run/systemd/sessions, which the systemd library API uses under the covers to get session information. Amusingly, this only affects ' who ', not ' w ', as ' w ' has no specific AppArmor profile.)