Bug 2283049
| Summary: | wall command does not work on Fedora 40 | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | M. Schlegel <moschlegbz> |
| Component: | util-linux | Assignee: | Karel Zak <kzak> |
| Status: | ASSIGNED --- | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | medium | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 42 | CC: | kzak, old486whizz |
| Target Milestone: | --- | Keywords: | Desktop, Reopened |
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2024-05-28 07:45:49 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
On kernel-6.8.10-300.fc40.x86_64, wall does not work in the same way as stated in the bug *** This bug has been marked as a duplicate of bug 2283016 *** Sorry, The wall(1) command follows the utmp database to get the list of terminals (see, for example, the w(1) output). The utmp is usually used for login/su terminals. Unfortunately, terminal emulators like gnome-terminal do not write to the utmp. Note that old, good Xterm writes to utmp. So this is not a bug from my point of view. This should be re-opened.
Evidence of the terminals existing in /run/utmp:
---
last -f /run/utmp
Tr0n tty7 Thu May 23 22:34 still logged in
Tr0n pts/5 :0 Thu May 23 22:48 still logged in
Tr0n pts/4 :0 Thu May 23 22:47 still logged in
Tr0n pts/3 :0 Thu May 23 22:38 still logged in
Tr0n Thu May 23 18:34 gone - no logout
Tr0n pts/1 :0 Thu May 23 22:38 still logged in
Tr0n pts/0 :0 Thu May 23 22:34 still logged in
reboot system boot 6.8.10-300.fc40. Thu May 23 17:09 still running
utmp begins Thu May 23 17:09:35 2024
---
Even worse - it doesn't work with SSH.
... SSH doesn't have >anything< to do with graphical terminals.
This seems to be because loginctl is being polled, and loginctl doesn't show shells / tty's - which are the things that you would want a broadcast message to appear on.
---
loginctl
SESSION UID USER SEAT TTY STATE IDLE SINCE
18 1000 Tr0n seat0 tty7 active no -
1 sessions listed.
---
This is the issue / bug.. Nothing to do with the fact that konsole/gnome-terminal haven't changed yet the behaviour has.
... Also, xterm doesn't work either.
--
old486whizz
Hmm... I see now it does not work as expected (compared to the old version). Sorry for the premature close. The problem is that systemd does not provide tty (sd_session_get_tty() returns nothing). We need to discuss this upstream (https://github.com/util-linux/util-linux/issues/2088). The old versions use classic utmp, but the latest version in Fedora uses data from logind. I forgot about this change. This message is a reminder that Fedora Linux 40 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 40 on 2025-05-13. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '40'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see it. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 40 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed. Still exists in 41 and 42, moved bug to 42 To update this, I'm on Fedora 42 using the 'wall' that comes with util-linux-2.40.4-7.fc42.x86_64
With both user and root accounts set to "mesg y", The only wall channel that doesn't work now is walling from root user to normal users. That's obviously the most important one
I can "wall" from a user and it's visible to the root user, and root sees his own "wall"
test 1) Root sends a wall, sees its own broadcast and user "mos" Does NOT see it.
root:~ # wall "this is wall talking from root user again at 14:23"
Broadcast message from root.home (pts/3) (Mon Apr 28 14:23:06 2
this is wall talking from root user again at 14:23
mos:~ $
(user mos see no 14:23 message from wall)
test 2) A wall sent from user "mos" is seen by root but not from the mos user himself
mos:~ $ wall "A wall statement from normal user at 14:25"
(user mos does not see own wall string)
root:~ #
Broadcast message from mos.home (pts/4) (Mon Apr 28 14:21:25 20
A wall statement from normal user at 14:25
==============================================
In this tests, I simply added mesg y to both users .bashrc, logged out of KDE and logged back in. Note that user "mos" has linger enabled, I'm not sure if this affects something like maybe the test should be done after rebooting.
loginctl show-user mos
UID=1000
GID=1000
Name=mos
Timestamp=Mon 2025-04-28 12:40:54 EDT
TimestampMonotonic=15710820
RuntimePath=/run/user/1000
Service=user
Slice=user-1000.slice
Display=6
State=active
Sessions=6 1
IdleHint=no
IdleSinceHint=0
IdleSinceHintMonotonic=0
Linger=yes
This is interesting too. I rebooted to check if flushing the linger on the "mos" user would help. Before logging into KDE, I used two virtual consoles to send walls out from "root" and "mos" both worked correctly. The most important one was that the normal user saw the wall from root in that test. But after logging into KDE and using two Konsole tabs where one was root and one was user "mos", the root -> mos wall was still not showing. |
While testing "wall" command in Fedora 40 from the util-linux-2.40.1-1.fc40.x86_64 package, it was noticed that wall does not send a message in any case. Two types of tests were tried 1 Shell mesg was set to 'y' Multiple "konsole" instances were started and test messages sent with "wall messagestring" no wall messages were displayed in the other windows. 2 Root was accessed with "sudo -i" and wall was attempted from there also, both as "wall -g usergroup teststring" and "wall teststring" where <usergroup> was the valid group of the user's konsoles on the display. No wall messages were seen. In all windows "mesg" was set to 'y' Reproducible: Always Steps to Reproduce: 1.Run wall command with a test string after setting mesg to y 2.Watch other terminal windows 3.See no wall messages posted from the wall command Actual Results: When a wall command is run with "mesg" set to 'y' in the the destination terminals, the wall message is not being shown in other terminals Expected Results: When a wall command is run with "mesg" set to 'y' in the the destination terminals, the wall message should be shown. kinfo output Operating System: Fedora Linux 40 KDE Plasma Version: 6.0.4 KDE Frameworks Version: 6.2.0 Qt Version: 6.7.0 Kernel Version: 6.10.0-0.rc0.20240516git3c999d1ae3c7.5.fc41.x86_64 (64-bit) Graphics Platform: Wayland Processors: 16 × AMD Ryzen 7 4800H with Radeon Graphics Memory: 15.0 GiB of RAM Graphics Processor: AMD Radeon Graphics inxi -G output Graphics: Device-1: AMD Navi 14 [Radeon RX 5500/5500M / Pro 5500M] driver: amdgpu v: kernel Device-2: AMD Renoir [Radeon RX Vega 6 ] driver: amdgpu v: kernel Device-3: Bison HD Webcam driver: uvcvideo type: USB Display: wayland server: X.org v: 1.20.14 with: Xwayland v: 23.2.6 compositor: kwin_wayland driver: X: loaded: amdgpu unloaded: fbdev,modesetting,radeon,vesa dri: radeonsi gpu: amdgpu,amdgpu resolution: 1920x1080 API: EGL v: 1.5 drivers: radeonsi,swrast platforms: wayland,x11,surfaceless,device API: OpenGL v: 4.6 compat-v: 4.5 vendor: amd mesa v: 24.0.7 renderer: AMD Radeon Graphics (radeonsi renoir LLVM 18.1.1 DRM 3.57 6.10.0-0.rc0.20240516git3c999d1ae3c7.5.fc41.x86_64) API: Vulkan v: 1.3.280 drivers: N/A surfaces: xcb,xlib,wayland tested on a non-standard kernel, but will rerun with kernel-6.8.10-300.fc40.x86_64 and comment if that is different