Hide Forgot
I'm not sure if this is a problem with smartd or with systemd, but my system does not send smart test emails when smartd starts. Apparently this is because smartd starts before the network service is available. SSMTP shows that it can't send the emails because the network is not yet available: Nov 14 10:02:37 18potato sSMTP[995]: Unable to locate mail.cs.byu.edu Nov 14 10:02:37 18potato sSMTP[995]: Cannot open mail.cs.byu.edu:25 This problem is new in Fedora 16 (with the same configuration in Fedora 15, the test emails were sent). smartmontools-5.42-1.fc16.x86_64 systemd-36-3.fc16.x86_64
please try if following helps: create /etc/systemd/system/smartd.service with content: .include /lib/systemd/system/smartd.service [Unit] After=network.target and reboot. Does it help?
*** Bug 754527 has been marked as a duplicate of this bug. ***
(In reply to comment #1) > please try if following helps: This seems to work. I've only rebooted once, so I can't say that I've tested thoroughly, but it looks good.
I tried this and it did not fix the problem. I still don't get test e-mails from smart at boot-up.
(In reply to comment #4) > I tried this and it did not fix the problem. I still don't get test e-mails > from smart at boot-up. what mail address do you use - local or some remote server? Do you use NetworkManager or static network configuration?
I use a remote server. It is a static IP done through networkmanager.
(In reply to comment #6) > I use a remote server. It is a static IP done through networkmanager. Are you using ssmtp or some other mail server on your local machine?
It is using what ever a clean Fedora 16 install uses. Once the machine is up I can send a mail to a remote machine using the simple 'mail' command.
I've tried to reproduce this with NetworkManager and with old network service. Both of them works fine. Please attach /var/log/mailog , /var/log/messages , /var/log/boot.log and complete line from /etc/smartd.conf . Feel free to remove passwords from files, but keep original host names. If you think it contains data that should not be visible in bugzilla, you can send them to my email address instead. Thanks
(In reply to comment #9) > I've tried to reproduce this with NetworkManager and with old network service. > Both of them works fine. Could you clarify whether you're trying to reproduce my issue or zingale's?
(In reply to comment #10) > (In reply to comment #9) > > I've tried to reproduce this with NetworkManager and with old network service. > > Both of them works fine. > > Could you clarify whether you're trying to reproduce my issue or zingale's? zingale's issue. You've said that proposed change helps for your case, so I don't need more information from you right now.
Created attachment 545784 [details] boot.log requested boot.log
Created attachment 545785 [details] maillog requested maillog
Created attachment 545786 [details] messages requested messages
I've attached the requested files.
I don't know what's going on here. Even if I disable sendmail and network, email from boot smartd test waits in mail queue and once network is up and sendmail started, it's send. There must me some problem with sendmail here, maybe related to systemd? Also smartmontools transition to systemd happened in Fedora 15 (where it is working), it broke in Fedora 16 where sendmail's transition to systemd happened. Reassigning to sendmail
I am unable to reproduce this. Could you provide bootchart generated by: $ systemd-analyze plot > boot.svg
Created attachment 561565 [details] boot.svg
On the original machine, the issue seems to be resolved with the latest updates. I have one other F16 machine that shows the problem. On that machine, all the disks hang off of a 3ware controller. Maybe that's the issue? The boot.svg is attached.
Well, it seems you are probably also affected by bug 789996. Please try to remove /etc/NetworkManager/dispatcher.d/10-sendmail. Then check whether the problem persists and please re-upload the new boot.svg.
This message is a reminder that Fedora 16 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 16. 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 WONTFIX if it remains open with a Fedora 'version' of '16'. 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 prior to Fedora 16's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 16 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 to click on "Clone This Bug" and open it against that version of Fedora. 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. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
I just updated to Fedora 18, and this bug persists there. Performing the fix in Comment 1 solves the problem.
(In reply to comment #22) > I just updated to Fedora 18, and this bug persists there. Performing the > fix in Comment 1 solves the problem. I did a bit debugging and for smooth operation I think we need: /lib/systemd/system/smartd.service [Unit] After=syslog.target network.target I did the following: /etc/smartd.conf: DEVICESCAN -T permissive -H -m root -M exec /usr/local/bin/mymailx -M test /usr/local/bin/mymailx mailx -v "$@" &>>/tmp/log Rebooted, cat /tmp/log: root... Connecting to [127.0.0.1] via relay... root... Deferred: Connection refused by [127.0.0.1] No problem, because it got queued, i.e.: # mailq -Ac /var/spool/clientmqueue (1 request) -----Q-ID----- --Size-- -----Q-Time----- ------------Sender/Recipient----------- r0LDDJoH001296 3 Mon Jan 21 14:38 root (Deferred: Connection refused by [127.0.0.1]) root Total requests: 1 And after the sendmail initialisation later, it is correctly send: # mailq -Ac /var/spool/clientmqueue is empty Total requests: 0 # cat /var/spool/mail/root From root Mon Jan 21 14:13:19 2013 Return-Path: <root> Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.14.6/8.14.6) with ESMTP id r0LDDJEV001369 for <root>; Mon, 21 Jan 2013 14:13:19 +0100 Received: (from root@localhost) by localhost.localdomain (8.14.6/8.14.6/Submit) id r0LDDJoH001296 for root; Mon, 21 Jan 2013 14:13:19 +0100 From: root <root> Message-Id: <201301211313.r0LDDJoH001296> Date: Mon, 21 Jan 2013 14:13:19 +0100 To: root Subject: SMART error (EmailTest) detected on host: localhost.localdomain User-Agent: Heirloom mailx 12.5 7/5/10 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit This email was generated by the smartd daemon running on: host name: localhost.localdomain DNS domain: localdomain NIS domain: (none) The following warning/error was logged by the smartd daemon: TEST EMAIL from smartd for device: /dev/sda [SAT] For details see host's SYSLOG. With updated smartd service file: After=syslog.target network.target it works more smoothly: # cat /tmp/log root... Connecting to [127.0.0.1] via relay... 220 localhost.localdomain ESMTP Sendmail 8.14.6/8.14.6; Mon, 21 Jan 2013 14:43:44 +0100 >>> EHLO localhost.localdomain 250-localhost.localdomain Hello localhost.localdomain [127.0.0.1], pleased to meet you 250-ENHANCEDSTATUSCODES 250-PIPELINING 250-8BITMIME 250-SIZE 250-DSN 250-ETRN 250-AUTH GSSAPI DIGEST-MD5 CRAM-MD5 250-DELIVERBY 250 HELP >>> MAIL From:<root> SIZE=553 AUTH=root 250 2.1.0 <root>... Sender ok >>> RCPT To:<root> >>> DATA 250 2.1.5 <root>... Recipient ok 354 Enter mail, end with "." on a line by itself >>> . 250 2.0.0 r0LDhiVw002478 Message accepted for delivery root... Sent (r0LDhiVw002478 Message accepted for delivery) Closing connection to [127.0.0.1] >>> QUIT 221 2.0.0 localhost.localdomain closing connection Michal, could you update the smartd service file? zingale do you use mailx? In such case the mail should be queued, with other clients the delivery may fail. Could you try my reproducer with your email address and provide the results? Also please provide the /var/log/maillog after the test (clean it before the test with echo -n > /var/log/maillog).
Is there anybody able to reproduce this with mailx (the smartd default mailer)? Could anybody provide the /var/log/maillog after the reboot? Or re-run the steps from comment 23?
This message is a reminder that Fedora 18 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 18. 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 WONTFIX if it remains open with a Fedora 'version' of '18'. 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 prior to Fedora 18's end of life. Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 18 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 to Fedora 18's end of life. 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.
Fedora 18 changed to end-of-life (EOL) status on 2014-01-14. Fedora 18 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.