Send Notification

What the Linux notification broadcaster does

This Automox Worklet™ broadcasts notifications to all logged-in users on Linux endpoints by detecting active terminal and GUI sessions, then delivering customized messages through appropriate delivery channels.

The Worklet uses the wall command to send notifications to all terminal sessions and the zenity utility to display graphical dialogs in GNOME and KDE desktop environments. This dual-delivery approach maintains message visibility across both command-line interfaces and graphical workstations without requiring you to manage multiple notification tools.

The Worklet includes customizable variables for message content, dialog title, window dimensions, and timeout duration. It gracefully handles endpoints where zenity or wall commands are not installed by attempting both delivery methods and reporting success or failure for each channel independently.

Why broadcast notifications to Linux endpoints

Email notifications get buried in overflowing inboxes and instant messages go unread, preventing users from receiving timely information about system maintenance, security alerts, policy changes, or required actions. Desktop notifications appear directly on the endpoint screen where users cannot miss them, providing immediate visibility for time-sensitive messages.

IT teams deploying software updates, applying security patches, or making configuration changes need a way to warn users before disruptive operations begin. A notification that appears 15 minutes before a scheduled reboot gives users time to save work and prepare for the interruption. This reduces data loss and improves user satisfaction with IT operations.

Security incidents, phishing campaigns, or suspicious activity require rapid communication to all affected users. When you detect a threat targeting your organization, you need the ability to send immediate warnings directly to endpoint screens rather than waiting for users to check email or visit the IT portal.

Compliance and security policies require documented user notification for certain actions like password changes, access reviews, or data handling procedures. Endpoint notifications provide an auditable method to prove users were informed about security requirements or policy updates.

How Linux notification delivery works

1. Evaluation phase: The Worklet returns exit code 1 during evaluation, signaling that remediation is needed. This maintains the notification delivery executes consistently across all endpoints.

2. Remediation phase: The Worklet attempts wall command delivery first. The wall utility broadcasts the message to all connected terminals immediately. If the wall command succeeds, the Worklet continues to GUI delivery. Next, the Worklet queries active user sessions using the who command and extracts unique usernames. For each detected user, it attempts to display a zenity warning dialog with the specified title, message text, window dimensions (500x100 pixels), and timeout duration (30 seconds). The dialog displays prominently on the user's GNOME or KDE desktop. If either wall or zenity commands fail, the Worklet logs the specific error and continues attempting alternate delivery methods. The Worklet exits with success code 0 only if at least one delivery method succeeded; it returns failure code 1 if both wall and zenity are unavailable or fail entirely.

Linux notification requirements

• Linux operating system on workstations or servers

• Bash shell environment (standard on all modern Linux distributions)

• wall command installed for terminal notification delivery (typically pre-installed on most distributions)

• zenity utility installed for graphical notifications in GNOME or KDE environments (install via apt-get install zenity on Debian/Ubuntu or dnf install zenity on RedHat/Rocky)

• Active user sessions for notification delivery (the Worklet detects logged-in users via the who command)

• Sufficient X11 display access for GUI notification delivery (desktop environments like GNOME or KDE must be running)

• Customizable variables: messageText (the alert content), title (dialog title, default Automox), width (dialog width, default 500), height (dialog height, default 100), and timeoutDuration (seconds before dialog closes automatically, default 30)

Expected notification delivery results

A notification appears on the endpoint's screen with the title and message you specified in the Worklet parameters. The notification displays in the native Linux notification system (notify-send) with your chosen icon and urgency level. Users see the notification immediately if they are logged in and actively using the endpoint, receiving your time-sensitive communication without email delays.

The notification remains visible for the duration specified in your Worklet configuration, typically five to 30 seconds depending on the message urgency and length. Users can dismiss the notification by clicking on it or wait for it to automatically disappear after the timeout period. This visible delivery confirms users have been notified of important maintenance windows, security alerts, or policy changes.

The notification delivery is logged in the Automox console as part of the Worklet execution results. You have an audit trail showing when notifications were sent to each endpoint and whether the notification delivery succeeded or failed, supporting compliance requirements for documented user notification.

If users are not logged in or if no display session is active, the notification may not appear or may appear when the next user logs in, depending on your specific notification implementation. For critical messages that must reach users, consider combining notification Worklets with email alerts or other communication channels.

How to validate send notification changes

1. Run this Worklet on a pilot Linux endpoint and review evaluation output for send notification.

2. Confirm Automox activity logs show successful completion and exit code 0.

3. Verify endpoint state using checks aligned to evaluation script logic, such as exit.

4. Validate remediation effects from script operations such as wall, who, read, then rerun evaluation for compliance.