BTW: There was a time before jessie: Every user who wants my help for running his own "personal computer" has to use the mate desktop, the last gtk2 … Sorry this thread should NOT evolve into a sequel to the "sequel of xbill" (2015). But at some point in the not to far future I may want to install excalibur and/or Xlibre … Re-reading my notes may be helpful to me, for others too.

My previous post was about the environment I'm working with …

**Sorry for the interruption**

While I am preparing to write the script about the hole Cave of the white rabbit an error occured with “up-to-date”:

Same may say Excalibur while others are watching monthy python's quest for the holy grail, and other others listen to musik …

The internet is dead, isn't it? Man comes next week, monday, when ready …

Very good find ...
With a very mislaid reply.

And that was that.

Why am I not surprised?

Best,

A.

refference: https://bugzilla.xfce.org/show_bug.cgi?id=13710

That said the problem seems NOT "who is the display manager?" NOR the existing difference between "terminal" or "console". BUT it may have to do with the write access to the terminal device by group "tty" (BTW: debian uses GID 5).

Tthe following checks with the xfce environment (BTW thanks to devuan! The usual xorg tools are available by default! Other distribution may request extra packages to install:-( show three different possibilities to use the wall utility.

1. Sending from xfce-terminal to an receiving xterm is OK, but OTHER xfce-terminals do NOT get the message, there is only a beep.

2. Sending from xterm to other virtual terminals works only if the following access rules for the devices apply:

ls -l /dev/pts/*

==> Addendum for su -, doas -s: the ownership of the device changes, but the source of the broadcast send is still guuml at pts/6 …

3. The situation is different on console:

ll /dev/tty{1..7}

BTW about my setup: The login manager slim is used only on other users' machines. Personally I prefer a more traditional setup with update-rc.d slim disable and a modified /etc/inittab if neccessary. After console login my ~/.profile checks for a hushlogin otherwise the default GUI is exec startx.

• Ok, my /dev/tty1 is xfce4 with the xfwm4 display manager but any GUI with freedesktop support may behave similar? Please note the dropped write privileges for "tty" after login.

• At /dev/tty2 a root login happend. (BTW the root password is very different from users' password;-) getty(8) prompts for a login name and then invokes login(1). That drops write access g-w, too. BUT wall broadcasts are received nethertheless!

• And /dev/tty3 is a hushlogin just to check out the all of the wall.

On devuan the /dev/console is used by kernel/eudev/xorg at the same time. So xconsole(1) is not of much help here.

Does the terminal emulator xterm(1) changing mode and ownership of the assigned device by own means or by some library used by kernels' console driver, too?

Conclusion

A) You can wall from xfce-terminal to both xterm and console, but you receive the broadcast only on xterm or console.

B) xfce-terminal do not get the message beside a beep.  Other GTK+ terminals may be affected, too.

C) A wall from root is send to all logged in user on all xterm and console. A xfce-terminal only beeps.

The session management of some "Desktop Environment" may differ because …

… requesting a unique user experience … Arrrggghhh .

I have mentioned the "beep only" for an older xfce-terminal, newer versions may have added features. Note the difference to xterm: one process spawns multiple virtual terminals in different windows and/or tabs, see help about terminal options.

Running `xfce4-notifyd-config` indicates there are many … more bells and whistles and turning wheels … not onlykids … a bridge to cross … No pun intended, rumours are that other GUIs have similar features. (BTW: the said shutdowm message was delievered via RPC, but the SMB/NMB clients didn't get the message :-)

Hopefully this sheds some light on the root causes of the topic.

--Gü

PS: finding the device names of all childs spawned by a terminal emulator like xfce-terminal:

ps --ppid $(pgrep xfce4-terminal) -o %y |
sed -E -n 's%^(pts/[0-9]+)%/dev/\1%p' 

• pgrep gets the PID of a process by pattern.

• ps --ppid PPID -o %y prints the attached tty of all childs of parent PPID.

• The sed does some reformating of previsious output.

Using the resulting device list with the echo workaround (see #15 ralph.ronnquist) is left as an exercise to the reader.

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

Well in Daedalus it does. And since there's no more /bin in Excalibur anyway looks like everything is /usr/bin now.

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

1. Totally agree! Make do or make new.

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

#!/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

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.

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.

Just to confirm:

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

Best,

A.

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.

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.