xorg and wall (usr/bin/wall)

bai4Iej2need · 2026-08-02 17:46:47

which wall
/usr/bin/wall

In ancient times (xdm, X11, EDIT:fvwm*) I used to send myself messages out of scripts using /usr/bin/wall .
So I knew that e.g. a job is finished or some action to be taken.
This message showed up on all consoles and xterms or similar.

Recently I tested with wall to learn about progress of a script, but lightdm traps the message .
Does not show up on an open mate terminal.
Actually lightdm traps the message.
It shows then up on logout EDIT: /login from Xorg and keeps the xserver to restart.
Manually I must do

service lightdm restart

to get a fresh login window until I logout again. Same game.

wall used to inform users from impending administration actions like shutdown or restart.
This function has been destroyed from the new habit of lightdm.

Apart from being a bug.
Now I have to find where this messages hang and they should be deleted on a restart of xserver.

It seems that the new generation of maintainers has no idea about multiuser systems.

Last edited by bai4Iej2need (Today 09:07:33)

Altoid · 2026-08-03 15:41:27

Hello:

Never used [wall] or [lightdm].
I am a [SLiM] enthusiast on a single-user WS.

That said and only to see if an [AI] answer can be (?) useful (I do not like it nor do I use it, this is just a test), out of curiosity I searched with Google and it came up with this without giving me an option to avoid it:

Terms used: [lightdm traps wall message]

Reply:

If your system hangs, delays, or traps a wall broadcast message when LightDM is active, it is typically because LightDM's greeter session listens to standard system log channels or terminal broadcasts, but lacks a standard terminal emulator to output the text cleanly.
Why the Trap Happens
Greeter Isolation:
LightDM's greeter runs under its own isolated unprivileged account (lightdm). If a system event (like a scheduled shutdown) fires a wall message, the system tries to inject it into all open pseudo-terminals (/dev/pts/*).
TTY/STDOUT Redirection:
The lightdm user owns a sub-process session that grabs TTY streams. Because it lacks a proper graphical notification daemon to catch terminal broadcasts, the text stream can buffer natively or loop inside systemd's logs (journalctl -u lightdm)

There's more, but this may get you on your way.
I am not sure about getting it done while using [lightdm].

Best,

A.

Last edited by Altoid (2026-08-03 19:45:50)

fsmithred · 2026-08-03 16:43:10

Turning off lightdm and using startx doesn't help. I still get the wall message on a console where I'm logged in but not in the desktop terminal.

Not sure if this helps. From 'man wall'

NOTES
Some sessions, such as wdm(1x), that have in the beginning of utmp(5) ut_type data a ':' character will not get
the message from wall. This is done to avoid write errors.

ralph.ronnquist · 2026-08-03 23:15:13

@Altoid, you do what you want at home, but stop immediately to post AI slop instead of knowledge.

If you don't know anything about the subject, then keep away. Noone is helped by AI slop whether it might be related or incidentally correct even. Since you don't know, you can't curate, and you just posted it because it looks convincing.

Stop that!

Altoid · Yesterday 00:13:36

Hello:

ralph.ronnquist wrote:

... stop immediately to post AI slop ...
... you can't curate ...
... posted it because it looks convincing.

Note taken.
Will not happen again.

That said, please do read the whole bit, especially these caveats*:

Never used [wall] or [lightdm].
... and only to see if an [AI] answer can be (?) useful ...
... this is just a test), out of curiosity I searched ...

* my fault, I should I have posted [CAVEAT] in capital letters somewhere.

Having made clear that I did not use [wall] or [lightdm], how could it possibly look convincing to me?
I did not look like anything but AI generated stuff, something I disclosed from the start of my post.

As such, my intention was for someone else (ie: who actually knew about the subject) to opine so that a check against what this AI thing actually spewed could be made.

Actually thought it was a good idea. 8^°

Best,

A.

ralph.ronnquist · Yesterday 04:04:04

Yes I realized your intention. But it's bad enough to try to run focussed discourse with "people that know" (also usually intended to be helpful), so when you don't know, just stay out of it... "listen and learn" so to speak.

Perhaps this thread can return to the wall program and how it behaves now versus in ancient times. (see eg post #3 above)

EDX-0 · Today 00:40:14

if i dare say, the issue is not so much a program named wall but rather the need for a program to send messages from other programs in a way the user can get them.

ralph.ronnquist · Today 04:56:06

Well, wall is a traditional program, see man wall and afaiui the issue is that it behaves differently now from how it has behaved; perhaps most probably because utmp database (another traditional thing, see man utmp) has change format, and in fact might also be one of those things that the kids have deprecated.

Certainly has little or nothing to do with wall papers.

How about waiting for someone that knows something about wall? I realise it can be really tempting to flaunt your ignorance just to have a post made, but it really isn't helpful.

EDX-0 · Today 06:57:15

worry not i have no problem sharing my ignorance with the world, that was the first thing i was taught about engineering at university

tangent aside, my point is not about ignorance but rather on function over a specific program, if a traditional program no longer works in the expected traditional way it did then it comes the question of is it the program or the setup around it

wall from the util-linux package should have the function of writing a message onto the terminals of all currently logged users, how does wall "get" the list of terminals associated with current users, on my system when i run who i get a list that contains my current terminal emulators (pts/N where N is an int starting at 0) but also contains tty7, the tty where the lightdm greeter spawns to initate the x11 server, the w command produces a similar list also showing the leader process inside each terminal, however no tty device is listed, doing a quick test running just wall "test" in my main machine on devuan 6 did produce the expected traditional behaviour of broadcasting a message to every running terminal i have

so it isn't much the program that isn't behaving traditionally but the setup around it, which begs the question if some specific program IS affecting the detection that wall should be able to do or is rather eating the message preventing it from propagating to the user terminals

all i can ask is what is bai4Iej2need's setup, a Desktop Environment, a window manager? which lightdm greeter?

i have lightdm with the slick greeter, i use a window manager but got some custom tooling so that my .xsession is a file that just launchs a program i wrote myself to be the session process which spawns my window manager, pulse audio daemons, picom and more, yet when i run wall from any regular running terminal it works

bai4Iej2need · Today 09:00:13

this is a standard daedalus install with mate as desktop.

aptitude show lightdm
Paket: lightdm                                  
Version: 1.26.0-8+devuan1

aptitude show mate-desktop
Paket: mate-desktop                             
Version: 1.26.0-2

aptitude show mate-terminal
Paket: mate-terminal                            
Version: 1.26.0-2

Repeated test : sent wall-message from root, arrived at 2 consoles (Alt-F2, owned by me), did not arrive at mate terminal.

Last edited by bai4Iej2need (Today 09:04:55)

bai4Iej2need · Today 10:05:22

tested the same on an excalibur virtual machine (under oracle virtualization) consoles are not accessible :
mate terminals do not show test message

fsmithred · Today 12:25:06

bai4Iej2need,

I think we're using the wrong terminal. I just tried it with xterm and it works. Does not matter if I use startx for openbox or openbox-session or if I use lightdm to start a full xfce destkop. Wall is happy to talk to xterm but does not work with xfce-terminal or qterminal. I didn't try any others.

ralph.ronnquist · Today 12:34:40

Following on from EDX-0, I tested wall in a lightdm + xfwm4 setup, as a non-root user as well as root.

From what I can gather wall will only write the message to root owned ttyN and pty/N. This is the same for both root and non-root, though of course also that it needs write permissing to the device; e.g. in my setup, non-root users in the tty group have such write access.

X11 terminal emulators are the ones setting up the pty.

I suppose it remains unclear whether wall has got revised decision logic, and/or different terminal emulators offer different pty handling.

Altoid · Today 12:46:50

Hello:

Just to confirm:

fsmithred wrote:

... tried it with xterm and it works.

Does not work with [xfce-terminal], [lxterminal] or [tilix].

Best,

A.

The officially official Devuan Forum!

#1 2026-08-02 17:46:47

xorg and wall (usr/bin/wall)

#2 2026-08-03 15:41:27

Re: xorg and wall (usr/bin/wall)

#3 2026-08-03 16:43:10

Re: xorg and wall (usr/bin/wall)

#4 2026-08-03 23:15:13

Re: xorg and wall (usr/bin/wall)

#5 Yesterday 00:13:36

Re: xorg and wall (usr/bin/wall)

#6 Yesterday 04:04:04

Re: xorg and wall (usr/bin/wall)

#7 Today 00:40:14

Re: xorg and wall (usr/bin/wall)

#8 Today 04:56:06

Re: xorg and wall (usr/bin/wall)

#9 Today 06:57:15

Re: xorg and wall (usr/bin/wall)

#10 Today 09:00:13

Re: xorg and wall (usr/bin/wall)

#11 Today 10:05:22

Re: xorg and wall (usr/bin/wall)

#12 Today 12:25:06

Re: xorg and wall (usr/bin/wall)

#13 Today 12:34:40

Re: xorg and wall (usr/bin/wall)

#14 Today 12:46:50

Re: xorg and wall (usr/bin/wall)

Board footer