Send Notification

What the Linux desktop notifier does

This Automox Worklet™ delivers notifications to logged-in users on a Linux endpoint at the moment a policy runs. The remediation script writes to both terminal sessions and graphical desktop sessions: wall broadcasts to every attached tty, and zenity displays a warning dialog on the X11 desktop of the first detected logged-in user.

Two delivery paths run in sequence. The script first checks for the wall binary and, if present, broadcasts the message to every attached tty with wall -n. It then checks for zenity, enumerates logged-in users by piping who through awk and sort -u, and runs sudo -u <user> DISPLAY=:0 zenity --warning --title --text --width --height --timeout against the first detected session. If neither wall nor zenity is installed, the script exits 1 with a clear stderr line so the failure shows up in Automox activity logs.

Five variables sit at the top of the remediation script: title (defaults to Automox), width (500 px), height (100 px), timeoutDuration (30 seconds), and messageText (the body string). Edit these inline before saving the policy, or expose them as policy variables so different teams can run the same Worklet with different copy. The script does not require notify-send, libnotify, or a D-Bus session bus on /run/user/$UID/bus to function; wall covers ttys and zenity covers X11 sessions without that dependency.

Why push alerts to the Linux desktop

Email and chat are not where a Linux user lives when the work is happening. A developer running a build, a DBA inside psql, or an SRE tailing logs in tmux is not going to see a Slack ping about a 2:00 a.m. patch window in time to save state. A wall broadcast lands directly in the terminal session, and a zenity warning dialog lands on the X11 desktop with a title bar that names the sender. The user sees the maintenance window before it starts, not after the box reboots underneath them.

Running this Worklet through Automox sends the message once and reaches active terminal and desktop sessions across GNOME, KDE, and bare ttys in the same policy pass. The activity log records which endpoints received the alert and which ones reported no active session, giving you an audit trail for every notification run.

How the wall and zenity delivery works

1. Evaluation phase: The evaluation script exits 1 unconditionally. This is an action Worklet, not a state-check Worklet, so the policy is designed to fire remediation on every scheduled run. The endpoint is always flagged non-compliant from Automox's perspective, which is how the platform knows to deliver the message.

2. Remediation phase: The script uses type wall to locate wall in PATH, then runs wall -n "$messageText" to push the body to every attached terminal. It checks the wall exit code and logs Failed to send to terminal(s) if the broadcast did not return 0. Next, it tests for zenity with type zenity, lists logged-in users with who | awk '{print $1}' | sort -u, and reads the first user into a sudo block that runs sudo -u "$user" DISPLAY=:0 zenity --warning --title="$title" --text "$messageText" --width $width --height $height --timeout=$timeoutDuration. The zenity dialog renders on the X11 display of that session. If both wall and zenity are missing, the script writes Notification commands WALL and ZENITY missing, unable to notify and exits 1. Otherwise it exits 0.

Linux desktop notification requirements

• Linux endpoint running a modern distribution with bash. RHEL, CentOS, Rocky, Alma, Fedora, Debian, and Ubuntu have all been verified.

• wall installed for terminal delivery. wall ships in util-linux on every mainstream distribution, so this is usually pre-satisfied. Confirm with type wall or which wall.

• zenity installed for GUI delivery on GNOME or KDE workstations. Install with apt-get install zenity on Debian or Ubuntu, dnf install zenity on RHEL, Fedora, Rocky, or Alma, and zypper install zenity on SUSE.

• At least one logged-in user reachable via who for the GUI path. If no user is logged in, wall still fires against any open ttys but zenity has no display to draw on.

• X11 display reachable as DISPLAY=:0. Pure Wayland-only sessions without XWayland are not covered by the default DISPLAY=:0 invocation; most desktop distributions still expose an X11 socket through XWayland, but verify on a pilot endpoint before fleet rollout.

• Five script variables to set in the remediation script: title (the dialog title bar string, default Automox), width (dialog width in pixels, default 500), height (dialog height in pixels, default 100), timeoutDuration (auto-dismiss after N seconds, default 30), and messageText (the body string).

• Root context on the endpoint. The Automox agent runs as root by default, which is what allows the script to run sudo -u <user> against an arbitrary logged-in account.

Expected behavior on the endpoint

On a workstation with one logged-in user, wall prints the message banner to every open terminal session for that user and any other accounts holding a tty. A zenity warning dialog opens on the X11 desktop within a second or two, sized 500 by 100 pixels by default, titled Automox, and auto-dismisses after the timeoutDuration value. On a headless server with no GUI, only the wall portion fires; zenity is either missing (and skipped) or present but unable to find a display, in which case the script logs Failed to send to GUI and continues.

The Automox activity log records the exit code and any stderr output. Exit 0 means at least one delivery channel succeeded. Exit 1 means both wall and zenity were missing, which is the only condition the script treats as a hard failure. Validate after a pilot run by checking the activity log for the endpoint and asking the user whether the dialog appeared; for unattended validation, run wall -n test from an SSH session and confirm the message appears in the user's open terminal.

For mixed environments, pair this Worklet with email or chat for the audit trail and use the desktop alert for the in-the-moment heads-up. Schedule it 15 to 30 minutes ahead of a reboot policy, a kernel patch window, or a software deployment so the user has time to save state. For longer notice windows, run it twice on the same policy: once an hour out with the warning copy, and once five minutes out with the final-call copy.