Bug 2491190

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.