Fedora Account System
Red Hat Associate
Red Hat Customer
File with issue: /usr/libexec/smartmontools/smartdnotify [Environment Context] - OS: Fedora Workstation 44 (Sway spin, installed via Fedora Everything netinst ISO). - User setup: Standard desktop/home user workstation (No root account created during install, single user leverages 'sudo'). - Network/Infra: Standalone local machine. No corporate environment, no centralized log monitoring agents (like Zabbix/Prometheus), and NO local mail server/MTA configured or installed by default. [Detailed Description of the Bug] The 'smartdnotify' script contains a flawed flow logic inside its 'case' statement. When the smartd daemon catches a critical hardware failure (e.g., "CurrentPendingSector", "OfflineUncorrectableSector"), it executes the script. The script starts by trying to pipe the message to the 'mail' command. Since standard Fedora desktop installations do not ship with a working local mail server out-of-the-box, this mail drop fails or disappears silently. Immediately after the mail block, the script enters: case "$SMARTD_FAILTYPE" in Since critical drive failure strings are not explicitly matched in the case options (only "EmailTest", "Health", "Temperature", and "Usage" are matched), they fall into the wildcard (*) block, which executes a hard 'exit 0'. Reproducible: Always Steps to Reproduce: Summary case 1 - SMARTD_FAILTYPE="CurrentPendingSector" smartdnotify script executes premature exit 0 on critical SMART drive failures, preventing terminal wall notifications on headless systems steps 0. open text tty console and log as user 1. Inspect the script logic at /usr/libexec/smartmontools/smartdnotify. Notice that inside the 'case "$SMARTD_FAILTYPE"' block, critical hardware failures fall into the wildcard (*) option, which executes a global 'exit 0'. 2. Simulate a critical hardware alert by exporting a critical failure type and calling the script manually: export SMARTD_FAILTYPE="CurrentPendingSector" export SMARTD_MESSAGE="Device: /dev/sda, 12 Currently unreadable (pending) sectors" export SMARTD_FULLMESSAGE="Simulated critical hardware failure" export SMARTD_SUBJECT="SMART error" export SMARTD_ADDRESS="root" /usr/libexec/smartmontools/smartdnotify 3. Check the exit status immediately after execution (echo $?). It returns 0. 4. Switch to any text tty console (e.g., Ctrl+Alt+F3). Observe that no 'wall' notification was printed to logged-in system administrators, meaning critical hardware alerts are completely silenced on headless systems if local mail is missing. 5. Observe that no desktop notification graphical popup (via mako/dunst/desktop notification daemons) appears on the user's active screen. ------------ Summary case 2 - export SMARTD_FAILTYPE="Temperature" smartdnotify relies on obsolete 'wall' command for warnings, rendering alerts completely invisible to modern desktop environments (Wayland/Sway) steps 0. open text tty console and log as user 1. Open a modern desktop session running on Wayland (such as Fedora Sway spin) and launch a terminal emulator (e.g., foot). 2. Simulate a non-critical hardware warning (like Temperature) which bypasses the script's early exit logic: export SMARTD_FAILTYPE="Temperature" export SMARTD_MESSAGE="Device: /dev/sda, temperature 45 Celsius" export SMARTD_FULLMESSAGE="Simulated temperature alert" export SMARTD_SUBJECT="SMART temp warning" export SMARTD_ADDRESS="root" /usr/libexec/smartmontools/smartdnotify 3. Observe that no desktop notification graphical popup (via mako/dunst/desktop notification daemons) appears on the user's active screen. 4. Switch to a virtual text console via Ctrl+Alt+F3. Notice that the warning message was printed there instead. Since standard desktop users work exclusively inside the graphical server session and do not keep raw text TTYs open, the script's fallback notification system remains entirely invisible to them. Actual Results: Due to the premature 'exit 0' inside the wildcard block of the case statement, the script terminates instantly for all critical errors. The 'wall' command is never reached for severe hardware issues. As a consequence, unless the user manually sweeps 'journalctl' regularly, critical drive failures become a dangerous silent blind spot for standard desktop users, defeating the purpose of having a local notification script. Expected Results: case 1 headless servers For critical drive failures, the script should NOT exit prematurely inside the 'case' block. It should proceed to the end of the file and execute the 'wall -n' command. This ensures that system administrators logged into text TTYs or headless servers receive an immediate broadcast on their terminals warning them about imminent hardware degradation, even if the local mail subsystem is unconfigured. case 2 graphical session The script should be modernized to detect if a graphical session is running (or leverage a fallback mechanism) and utilize 'notify-send' (or talk to DBUS/Desktop Notification Daemons) instead of relying solely on 'wall'. This would allow standard desktop and home users running Wayland environments (like Sway, GNOME, or KDE) to receive native graphical popup alerts on their screens when drive warnings occur, rather than having the messages sent exclusively to hidden text TTYs. Additional Information: case 1 headless servers The 'case' filtering logic inside /usr/libexec/smartmontools/smartdnotify should be redesigned to wrap ONLY the 'wall' command string configuration, instead of calling a global 'exit 0' that halts the entire script execution prematurely. This will allow critical hardware alerts to naturally reach the fallback notification commands at the bottom of the script. case 2 graphical session Consider adding a check inside the script to detect if a graphical session or DBUS is available (e.g., checking $WAYLAND_DISPLAY, $DISPLAY, or running desktop environments) and implement a fallback that uses 'notify-send' or a similar desktop-notification mechanism. Relying purely on 'wall' makes the package ineffective for modern default Fedora spins like Sway, GNOME, and KDE.
Two way to send notification to desktop user ### Option 1: using `gdbus` ```bash gdbus call --session \ --dest org.freedesktop.Notifications \ --object-path /org/freedesktop/Notifications \ --method org.freedesktop.Notifications.Notify \ "smartd" 0 "dialog-warning" "SMART error: CurrentPendingSector" "Device: /dev/sda, 12 Currently unreadable (pending) sectors\n\nSimulated critical hardware failure" [] {} 10000 ``` --- ### Option 2: using `dbus-send` ```bash dbus-send --session \ --print-reply \ --dest=org.freedesktop.Notifications \ /org/freedesktop/Notifications \ org.freedesktop.Notifications.Notify \ string:"smartd" \ uint32:0 \ string:"dialog-warning" \ string:"SMART error: CurrentPendingSector" \ string:"Device: /dev/sda, 12 Currently unreadable (pending) sectors Simulated critical hardware failure" \ array:string:[] \ dict:string:variant:{} \ int32:10000 ```
Created attachment 2148950 [details] Draft Implementation for /usr/libexec/smartmontools/smartdnotify Summary of Suggested Fix Here is a draft of the proposed workaround to address the lack of desktop notifications under modern systemd and graphical environments (such as Sway, GNOME, etc.). Please note: This script is a conceptual draft (proof of concept) rather than a fully polished, production-ready, or extensively tested solution. It is intended to point the packaging and development team in the right direction to show how system-level services can gracefully bridge notifications to user sessions via D-Bus without violating security boundaries.
[Historical Context / Regression] In earlier versions of the package (circa 2011), the script properly included native desktop notification support using '/usr/bin/notify-send' right after the mail block. A subsequent redesign replaced this clean approach with a 'case' statement that falls back strictly to the 'wall' command. This change represents a major regression for desktop spin users, as it completely stripped away graphical alert capabilities that were previously standard. ### Historical Context & Regression Evidence The `smartdnotify` script previously possessed native desktop notification support. In 2011, the script correctly implemented a clean approach that attempted to send an email and immediately followed up with a graphical user alert via `notify-send`. * **2011 Commit Link:** https://src.fedoraproject.org/rpms/smartmontools/c/098dac6bf5454d116825aa81773f29f5145b252d?branch=rawhide * **Script History Source:** https://src.fedoraproject.org/rpms/smartmontools/history/smartdnotify?identifier=rawhide #### Complete 2011 Script Version: ```sh #! /bin/sh # Send mail echo "$SMARTD_MESSAGE" | mail -s "$SMARTD_FAILTYPE" "$SMARTD_ADDRESS" # Notify desktop user /usr/bin/notify-send -t 0 "WARNING: Your hard drive is failing" \ "Description: $SMARTD_MESSAGE" ``` ### Modern Verification Test To verify if this older approach is still viable on modern modern Wayland compositions, the exact same binary command was manually executed on a fresh **Fedora Sway 44** desktop session: ```bash /usr/bin/notify-send -t 0 "WARNING: Your hard drive is failing" ``` **Test Result:** Success. The graphical notification popup is properly triggered and completely visible to the desktop user via the native notification daemon. Replacing this functional implementation with the current `case` structure and the obsolete `wall` command stripped away essential desktop alerts, representing a clear usability regression for modern graphical Fedora spins. ### Package Version Environment ```text $ rpm -qf /usr/libexec/smartmontools/smartdnotify smartmontools-7.5-6.fc44.x86_64 ```
Hi, don't forget there should be only one issue per bugzilla. I will create a clone
the first half is tracked in bug #2506055
Fifteen year old change that actually fixed previously non-working state does not qualify as regression. Clearing keyword. Those example solutions are incorrect/incomplete as you need user session to be actually able to display such notification message to a user. Don't forget that multi-seat setups exist as well. You can't test it by running it yourself, you have to let smartd run it so it has proper runtime context. (I'm not asking you to fix the suggested solution or provide a different one. Just explaining the situation that it's not as straightforward) wall should work fine for both headless servers and desktops. When I test it I get the messages from smartd. In KDE there is kwrited service that listens for wall messages and displays popup notification when it receives some. I guess there should be something similar in other DEs. I will check it later. I estimate that I will be able to look at this issue a week after the next one. ------------- note: Please don't use AI for bug reports. A - it generates way too much useless text, more text does not make more better. Someone has to read it and it wastes time. B - you do not gain any knowledge, only AI "does", which makes it difficult to discuss/explain anything in such bug report.
Fair point. You are probably right. I ran another, more standard test (see below). I think the issue is a bug exclusive to Fedora Sway. Details below: ## 1. Verifying Mail Utility Installation > **Note:** No manual installation or removal of mail packages was performed on this Fedora Sway setup. ```bash $ mail bash: mail: command not found $ rpm -q mailx package mailx is not installed $ rpm -qf /usr/bin/mail error: file /usr/bin/mail: No such file or directory ``` --- ## 2. Configuring Test Alert in `smartd` Append `-M test` to the existing directive in `/etc/smartmontools/smartd.conf`: ```text # Test flag added to verify desktop notifications on Fedora Sway DEVICESCAN -H -m root -M exec /usr/libexec/smartmontools/smartdnotify -n standby,10,q -M test ``` --- ## 3. Monitoring and Triggering the Alert Test ### Monitoring Logs Inspect the latest log entries prior to restarting the service: ```bash sudo journalctl -u smartd -e ``` **Last log entry before service restart:** ```text Jul 28 06:11:37 fedora systemd[1]: Started smartd.service - Self Monitoring and Reporting Technology (SMART) Daemon. ``` ### Restarting the Service Restart `smartd` to trigger the alert simulation: ```bash sudo systemctl restart smartd.service ``` ### Verification Output Output generated in system logs following the restart: ```text SMART Disk monitor: TEST EMAIL from smartd for device: /dev/sda [SAT] SMART Disk monitor: TEST EMAIL from smartd for device: /dev/sda [SAT] ``` ### Expected Result in Fedora Sway Notification Area After restarting `smartd.service`, the notification banner reading "TEST EMAIL from smartd for device: /dev/sda [SAT]" should render correctly in the top-right corner of the screen. ## Verifying the Active Notification Daemon Checking if `dunst` is running on the system using `ps` and querying the DBus notification interface: ```bash $ ps aux | grep -E "dunst|mako|swaync|fnott|notification" | grep -v grep user1 19620 0.0 0.3 811608 24500 ? Ssl 08:26 0:00 /usr/bin/dunst $ dbus-send --session --print-reply --dest=org.freedesktop.Notifications /org/freedesktop/Notifications org.freedesktop.Notifications.GetServerInformation method return time=1785238164.604693 sender=:1.32 -> destination=:1.34 serial=16 reply_serial=2 string "dunst" string "knopwob" string "1.13.2" string "1.2" ``` --- ## Testing Desktop Notifications with notify-send in command line Executing a manual notification test via `notify-send`: ```bash $ /usr/bin/notify-send -t 0 "WARNING: Just checking" ``` **Result:** The notification banner renders correctly via `dunst` in the top right corner of the screen.
Errata: There is no option to edit my own comments—only the main post at the top can be edited. ### Verification Output Output generated in system logs following the restart: ```text Jul 28 07:56:43 fedora smartd[10460]: Executing test of /usr/libexec/smartmontools/smartdnotify to root ... Jul 28 07:56:43 fedora smartd[10460]: Test of /usr/libexec/smartmontools/smartdnotify to root: successful ```
### Actual Result in Fedora Sway Notification Area No notification was visible in the top right area, only in the log as mentioned before.
FEDORA-2026-eb5363b2a7 (smartmontools-7.5-9.fc43) has been submitted as an update to Fedora 43. https://bodhi.fedoraproject.org/updates/FEDORA-2026-eb5363b2a7
FEDORA-2026-92cefb93ae has been pushed to the Fedora 44 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2026-92cefb93ae` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2026-92cefb93ae See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2026-eb5363b2a7 has been pushed to the Fedora 43 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2026-eb5363b2a7` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2026-eb5363b2a7 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2026-92cefb93ae (smartmontools-7.5-9.fc44) has been pushed to the Fedora 44 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2026-eb5363b2a7 (smartmontools-7.5-9.fc43) has been pushed to the Fedora 43 stable repository. If problem still persists, please make note of it in this bug report.