Hi folks! It seems like we have a regression since our trixie fleet upgrade, where delayed reboot notifications don't show up on SSH consoles anymore. For background, we manage about 150 Debian servers at the Tor project and have some automation around reboots where we issue `shutdown -r +10 "security upgrade` commands on a regular basis. We expect those to give our shell users a heads up that stuff is going to happen, particularly people logged into IRC bouncers or working over SSH otherwise. Since the trixie upgrade, this just stopped working altogether. We don't see reboot notifications. It's an open question for us whether we really need this anymore: more and more of our deployments are done with containers and CI, and we kind of hope to get rid of the old "SSH over and do things" manual models. But we still have it, so, for now, I'm kind of assuming this is supposed to work. This is tracked as an issue on our end in: https://gitlab.torproject.org/tpo/tpa/team/-/issues/42137 I understand that it might work under some circumstances. I've heard reports like "this works fine for me", but this is real for us: across the entire fleet, we never see, as far as I can tell, any of those notifications anymore, and there's a clear correlation with the trixie upgrade. Specifically, this was previously discussed in #1087642, and #1075733, and it seems both issues were closed as "works for me" and "tests pass", but this just *doesn't* "work for me". This bug is real and current. It's unclear to me how to actually debug this either, and maintainers have not provided clear guidance on how to actually start debugging this problem. I'm not very familiar with the systemd codebase, so I don't know exactly where to start. I'm hoping Debian systemd folks could help! I was told this could be related to upstream issue #36930 (sd_get_sessions doesn't report TTY information), and we do match the symptoms in the sense that our logged in users do not have a TTY attached: anarcat@idle-dal-02:~$ loginctl SESSION UID USER SEAT LEADER CLASS TTY IDLE SINCE 22888 0 root - 844925 user - no - 22889 0 root - 844931 manager-early - no - 22890 2128 anarcat - 844965 user - no - 22891 2128 anarcat - 844970 manager - no - 4 sessions listed. A fix for that (5af674214abbe16ee57352de24eaef5dc97afdd1) was shipped in 258-rc1, while trixie has only 257.9-1~deb13u1. I wonder if the "it works for me" reports are from users running unstable that have the above fix. I was hoping a backport of the patch could resolve the issue, but then I was also told our systemd ships wihout utmp support, so all of the above is essentially moot (or is that the root cause?). Anyways, would love a little more guidance here to remove this small irritant! a.