Fedora Account System
Red Hat Associate
Red Hat Customer
Description of problem: The default smartd_opts in /etc/sysconfig/smartmontools include the --capabilities argument, which makes smartd drop most privileges on startup. As documented in smartd(8), this disables all alerts (e-mails, messages to local consoles, possible plugins in /etc/smartmontools/smartd_warning.d/ like desktop notifications). The alert notification machinery (/etc/smartmontools/smartd_warning.sh) will simply never be run by smartd when --capabilities is enabled. This makes smartd in the default configuration close to useless, because the only thing it does is write even critical alerts to the syslog, which most users do not monitor closely enough to notice a warning of an imminent disk failure before it is too late. Version-Release number of selected component (if applicable): smartmontools-7.2-2.fc32.x86_64 How reproducible: Any time on demand Steps to Reproduce: 1. Add "-M test" to the default uncommented DEVICESCAN line in /etc/smartmontools/smartd.conf to trigger a test alert 2. systemctl restart smartd.service Actual results: No alert is ever generated. Syslog messages like the following will be logged, pointing at the problem: Device: /dev/sda [SAT], --capabilites is set, mail will be suppressed. Device: /dev/nvme0, --capabilites is set, mail will be suppressed. Expected results: Syslog messages like the following, together with a warning e-mail and message to all consoles. Executing test of /usr/libexec/smartmontools/smartdnotify to root ... Test of /usr/libexec/smartmontools/smartdnotify to root: successful Executing test of /usr/libexec/smartmontools/smartdnotify to root ... Test of /usr/libexec/smartmontools/smartdnotify to root: successful Additional info: Removing the "--capabilities" argument from /etc/sysconfig/smartmontools and restarting smartd fixes the issue.
This message is a reminder that Fedora 32 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 32 on 2021-05-25. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '32'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 32 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
*** Bug 1954018 has been marked as a duplicate of this bug. ***
Fedora 32 changed to end-of-life (EOL) status on 2021-05-25. Fedora 32 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.
Could this be marked as duplicate of bug 1962593?
these are two separate bugs to track the issue in different products
Good point, thanks. For Fedora we will likely need wider set of capabilities if exim is expected to work there as well, as compared to RHEL.
FEDORA-2021-6367f6f394 has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2021-6367f6f394
FEDORA-2021-1442a1b955 has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-1442a1b955
FEDORA-2021-1442a1b955 has been pushed to the Fedora 34 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-1442a1b955` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-1442a1b955 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2021-6367f6f394 has been pushed to the Fedora 33 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-6367f6f394` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-6367f6f394 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2021-6367f6f394 has been pushed to the Fedora 33 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2021-1442a1b955 has been pushed to the Fedora 34 stable repository. If problem still persists, please make note of it in this bug report.
Originally posted on wrong thread (https://bugzilla.redhat.com/show_bug.cgi?id=1962593#c21): Don't know if this is the right place to comment, but I'm on Fedora 35 with smartmontools 7.2-11 (so supposedly this is fixed IIUC), but I'm still unable to set smartd up to send me notifications or emails. When I use the "-m" option in smartd.conf it says that "mail" cannot be found, so the redirection to "sendmail" seems to not be working. When trying to circumvent that by using "-M exec" and pointing to my own script SELinux smacks it down (doesn't want to let smartd execute my script). When moving my code to one of the smartmontools example scripts in /usr/share/doc[...] it allows executing the existing Example (after chmod) but smacks down the attempt to execute the commands within. The last thing I tried was to comment everything in one of the Example scripts and just put notify-send 'test' there and then also added a new policy to SELinux so it allows executing the "notify-send" command, but I still don't get a notification when running with "-M test" upon restart even though in "systemctl status smartd" it says that the test was executed successfully (and no SELinux action since I introduced the automatically recommended policy). When I run that same Example script manually, even without root, it gives me the notification just fine. As an aside, I for some reason now can't remove the custom policy from SELinux, either, ("sudo semodule -r my-notifysend.pp"), as it says "No such file or directory", even though "sudo semodule -l" does list the module... This has been quite a frustrating process...it shouldn't be so hard to have smartd notify me about problems. Has this actually been fixed? Apologies if this is the wrong place for comment; if it is, should I open a new issue? Now replying to https://bugzilla.redhat.com/show_bug.cgi?id=1962593#c22 This is a RHEL bz. The Fedora bz is 1954015. The question would be, what mail client do you use? I use Thunderbird, but I have no idea how that may tie into sendmail or postfix...I definitely don't have "mail" installed, but "sendmail" or "postfix" is available and I seem to have an inbox for it under /var/spool/postfix/incoming Basically I don't actually care so much about email, I just want to be notified by smartd when a problem occurs and since I'm usually at the desktop station when it runs, a notification would be fine. However, as said above, even this simple command (notify-send) does not work, even after I created the individual SELinux policy based on the automated recommendation.
(In reply to Christian F. from comment #13) > > When I use the "-m" option in smartd.conf it says that "mail" cannot be > found, so the redirection to "sendmail" seems to not be working. It is not clear at which point "it" says that. However, message about mail command not getting found indicates that something (smartd?) knows that it should be sending those notification emails. Which was the whole point of this bugzilla, to make running with capabilities not turn off mail notifications, so what you see suggests that this bugzilla was indeed fixed. The issues you face seem to be related to some other configuration or potentially rpm dependencies so I suggest you file separate bugzilla where you describe the exact configuration, steps to reproduce, and actual and expected results.
(In reply to Jan Pazdziora from comment #14) > (In reply to Christian F. from comment #13) > > > > When I use the "-m" option in smartd.conf it says that "mail" cannot be > > found, so the redirection to "sendmail" seems to not be working. > > It is not clear at which point "it" says that. However, message about mail > command not getting found indicates that something (smartd?) knows that it > should be sending those notification emails. Which was the whole point of > this bugzilla, to make running with capabilities not turn off mail > notifications, so what you see suggests that this bugzilla was indeed fixed. > > The issues you face seem to be related to some other configuration or > potentially rpm dependencies so I suggest you file separate bugzilla where > you describe the exact configuration, steps to reproduce, and actual and > expected results. Done. Tracking under 2073614.