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 (Yesterday 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 · 2026-08-04 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 · 2026-08-04 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 · Yesterday 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 · Yesterday 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 · Yesterday 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 · Yesterday 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 (Yesterday 09:04:55)

bai4Iej2need · Yesterday 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 · Yesterday 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 · Yesterday 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 · Yesterday 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.

ralph.ronnquist · Yesterday 23:26:03

Please re-read the posts further above. E.g. wall "works with" xfce-terminal quite well.

It really isn't down to a choice of which (virtual) terminal is used but most significantly that the tty/pty must be owned by root. I have not used wall regularly enugh to be certain, but that particular restriction might be a newish thing (at the timescale of wall).

The other restriction is that the user of wall must have write access to the device being written to. As mentioned above, wall will consider all /dev/ttyN and /dev/pts/N, and then write to those with applicable write access and owner being root.

The interested reader may experiment with, say

$ echo foobar > /dev/pts/3

to see which of their virtual terminal that ends up in. Or to be more targeted, they may first run

$ tty

in a shell to determin which pty device node to use for that shell, and then go crazy writing to it.

bai4Iej2need · Today 07:47:31

what I understand until now :
wall (root) writes to all open tty1 - tty7
Does not write to ptys not owned by root

ps aux | grep tty7
root      1369  2.1  0.2 26629380 192864 tty7  Ssl+ 08:57   0:04 /usr/lib/xorg/Xorg :0 -seat seat0 -auth /var/run/lightdm/root/:0 -nolisten tcp vt7 -novtswitch

this is owned by root.
The user (uid>=1000) logs out of his x session.
lightdm is restarted owned by user lightdm (111:118) from init process
User (uid>=1000) logs in again through the login window.
Then pam? or some authorization process kills the lightdm process, because the writing by wall has confused the rights.
The wall messages of the past show up in the tty7 and no x-session appears.
lightdm must be restarted to get a fresh lightdm login window.
This time the login of uid=1000 is successful, but after the logout above procedure repeats.
The wall messages are still there, augmented by all test messages in the mean time.
I can confirm, that xterm opened by uid 1000 receives the wall message from root, but mate terminal not

It looks like i must trace a failed login session to find its cause.

EDX-0 · Today 08:55:12

at this point it begs the question if it would not be better to just write a program to do what wall(1) is supposed to do but in a less obtuse way, i do not think it would be too difficult to write something that has a correct and predictable behaviour, after all i quickly cobbled together this snippet out of code that exists in pywal

#!/bin/python3

# SPDX-License-Identifier: MIT

import logging
import os
import platform
import glob
import sys
import subprocess

def setup_logging():
    """Logging config."""
    logging.basicConfig(
        format=(
            "[%(levelname)s\033[0m] "
            "\033[1;31m%(module)s\033[0m: "
            "%(message)s"
        ),
        level=logging.INFO,
        stream=sys.stdout,
    )
    logging.addLevelName(logging.ERROR, "\033[1;31mE")
    logging.addLevelName(logging.INFO, "\033[1;32mI")
    logging.addLevelName(logging.WARNING, "\033[1;33mW")

setup_logging()
OS = platform.uname()[0]

has_fcntl = False
fcntl_warning = ""

try:
    import fcntl

    has_fcntl = True
except ImportError:
    fcntl_warning = "{}, {}".format(
        "can't skip blocking io in current platform",
        "program could hang indefinitely",
    )

def create_dir(directory):
    """Alias to create the cache dir."""
    os.makedirs(directory, exist_ok=True)

def save_file(data, export_file):
    """Write data to a file."""
    create_dir(os.path.dirname(export_file))

    if has_fcntl:
        try:
            with open(export_file, "w") as file:
                # Get the current flags and add non-blocking mode
                # to skip TTYs suspended by Flow Control
                # https://www.gnu.org/software/libc/manual/html_node/Getting-File-Status-Flags.html
                # https://www.gnu.org/software/libc/manual/html_node/Open_002dtime-Flags.html
                flags = fcntl.fcntl(file, fcntl.F_GETFL)
                fcntl.fcntl(file, fcntl.F_SETFL, flags | os.O_NONBLOCK)
                file.write(data)
        except PermissionError:
            logging.warning("Couldn't write to %s.", export_file)
        except BlockingIOError:
            logging.warning(
                "Couldn't write to %s, not accepting data", export_file
            )
    else:
        try:
            with open(export_file, "w") as file:
                file.write(data)
        except PermissionError:
            logging.warning("Couldn't write to %s.", export_file)

def send_to_term(message, to_send=True):
    """Send colors to all open terminals."""
    if OS == "Darwin":
        devices = glob.glob("/dev/ttys00[0-9]*")
    elif OS == "OpenBSD":
        devices = subprocess.check_output(
            "ps -o tty | sed -e 1d -e s#^#/dev/# | sort | uniq",
            shell=True,
            universal_newlines=True,
        ).split()
    else:
        devices = []
        patterns = ["/dev/pts/[0-9]*", "/dev/tty[1-6]"]
        for pattern in patterns:
            devices.extend(glob.glob(pattern))

    if not has_fcntl:
        logging.warning(fcntl_warning)

    # Send data to open terminal devices.
    if to_send:
        for dev in devices:
            if dev == "/dev/pts/0":
                if (
                    os.environ.get("XDG_CURRENT_DESKTOP") == "KDE"
                    or os.environ.get("DESKTOP_SESSION") == "plasma"
                ):
                    continue
            if dev == "/dev/tty7":
                continue
            save_file(message, dev)

def main():
    send_to_term(sys.argv[1])

if __name__ == "__main__":
    main()

the snippet is intentionally naive as a showcase of some quickly thrown together thing, it cares not for differentiating root from regular user just writes to whichever file it can open in "w" mode, the glob pattern intentionally avoids /dev/tty7 and just in case when writing to all terminal devices it explicitly avoids /dev/tty7 for good measure

the script could be made configurable (again this is just a quick cobbled together idea) to write only to specific patterns and add more filters to exclude any tty where a display manager lives

since this script already only cares that it can write to the target file, a shell wrapper could be put around to launch the script under it's own user, call it something like write_to_all_terminals and add a udev rule to give write permissions over all terminal devices (/dev/tty* and /dev/pts/*), then when the wrapper is called it will send whichever message is passed to all terminals

again this is just an idea.

edit: did not notice that the whole logging setup was initiated AFTER the first time the logging function could be called, anyway it is fixed

Last edited by EDX-0 (Today 08:58:40)

greenjeans · Today 13:30:36

EDX-0

1. Totally agree! Make do or make new.

2. neat script but : #!/bin/python3 ?

EDX-0 · Today 18:39:41

2. neat script but : #!/bin/python3 ?

i guess it should be #!/usr/bin/python3 but since usrmerge it makes no difference whatsoever as /bin is the same as /usr/bin

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 2026-08-04 00:13:36

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

#6 2026-08-04 04:04:04

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

#7 Yesterday 00:40:14

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

#8 Yesterday 04:56:06

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

#9 Yesterday 06:57:15

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

#10 Yesterday 09:00:13

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

#11 Yesterday 10:05:22

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

#12 Yesterday 12:25:06

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

#13 Yesterday 12:34:40

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

#14 Yesterday 12:46:50

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

#15 Yesterday 23:26:03

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

#16 Today 07:47:31

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

#17 Today 08:55:12

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

#18 Today 13:30:36

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

#19 Today 18:39:41

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

Board footer