smartd configuration problem

[Robert McBroom]

Boot process f40 system stops for a long time with a problem with 
smartd. Seems to access the system drives and note that they are SMART 
capable. The following entries are in the journal

smartd[977]: Warning via /usr/libexec/smartmontools/smartdnotify to root 
produced>>

smartd[977]: No configuration file found at (null) or /etc/esmtprc

After multiple entries

smartd[977]: No configuration file found at (null) or /etc/esmtp

The files referenced are not in /etc. Don't see such files on a f39 system

What is the system looking to find and where can it be found.

[Roger Heflin]

Someone seems to have added it to setup a snmp config.   It is
unlikely you want an snmp config/install, its only use is for external
monitoring via the network (without ssh access) and is for the most
part not being used much anymore.

You might do a man smartd.conf and see if there is an option to
disable snmp config completely.

I also disable smartd because generally it is less than useful (I have
had too many "your disk is going to fail soon" notifications where the
disk stopped working >3 years later--so the warning was useless, I
have also had disks fail that smartd did not ever report as failed).
 Generally I view its reliability is so bad the tool is actually WORSE
than useless since it scares you with incorrect warnings, and fails to
report real (usually bad sector issues) correctly.

I replace it with simply taking a report a day for each disk and when
disks act up I see if the bad sectors count are rising on one of the
disks.

On Fri, Aug 16, 2024 at 10:33 AM Robert McBroom via users
 wrote:
> Boot process f40 system stops for a long time with a problem with smartd. Seems to access the system drives and note that they are SMART capable. The following entries are in the journal
>
> smartd[977]: Warning via /usr/libexec/smartmontools/smartdnotify to root produced>>
>
> smartd[977]: No configuration file found at (null) or /etc/esmtprc
>
> After multiple entries
>
> smartd[977]: No configuration file found at (null) or /etc/esmtp
>
> The files referenced are not in /etc. Don't see such files on a f39 system
>
> What is the system looking to find and where can it be found.
>
> --
> _______________________________________________
> users mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedoraproject.org/archives/list/[e-mail]
> Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

[David King]

On 8/16/24 11:32, Robert McBroom via users wrote:
> Boot process f40 system stops for a long time with a problem with 
> smartd. Seems to access the system drives and note that they are SMART 
> capable. The following entries are in the journal
>
> smartd[977]: Warning via /usr/libexec/smartmontools/smartdnotify to 
> root produced>>
>
> smartd[977]: No configuration file found at (null) or /etc/esmtprc
>
> After multiple entries
>
> smartd[977]: No configuration file found at (null) or /etc/esmtp
>
> The files referenced are not in /etc. Don't see such files on a f39 
> system
>
> What is the system looking to find and where can it be found.

esmtp is a mail transfer agent (MTA).  Use "sudo dnf info esmtp" to see 
its Fedora package info.  I know that on Fedora smartd is configured by 
default to send e-mail when it detects a problem on a disk.  It may be 
that your system is configured to use esmtp to send mail and smartd has 
found a disk problem and is hanging when it tries to email you because 
esmtp is not configured properly. If that is the case then you would 
need to put the proper mail server, userid and password into file 
mentioned, /etc/esmtprc, to make it all work.  Or, you could go into 
/etc/smartmontools/smartd.conf and change the configuration so it 
doesn't try to send emails.

To check to see if esmtp is actually the MTA your system is configured 
to use: "sudo alternatives --config mta"

To confirm that there is a disk problem that smartd is trying to notify 
you about: do "sudo smartctl --scan" to find the disk devices smart 
knows about and then do "sudo smartctl -a /dev/sdX" for one of the 
listed devices.

[Robert McBroom]

On 8/16/24 11:00 PM, David King wrote:
> On 8/16/24 11:32, Robert McBroom via users wrote:
> > Boot process f40 system stops for a long time with a problem with 
> > smartd. Seems to access the system drives and note that they are 
> > SMART capable. The following entries are in the journal
> >
> > smartd[977]: Warning via /usr/libexec/smartmontools/smartdnotify to 
> > root produced>>
> >
> > smartd[977]: No configuration file found at (null) or /etc/esmtprc
> >
> > After multiple entries
> >
> > smartd[977]: No configuration file found at (null) or /etc/esmtp
> >
> > The files referenced are not in /etc. Don't see such files on a f39 
> > system
> >
> > What is the system looking to find and where can it be found.
>
> esmtp is a mail transfer agent (MTA).  Use "sudo dnf info esmtp" to 
> see its Fedora package info.  I know that on Fedora smartd is 
> configured by default to send e-mail when it detects a problem on a 
> disk.  It may be that your system is configured to use esmtp to send 
> mail and smartd has found a disk problem and is hanging when it tries 
> to email you because esmtp is not configured properly. If that is the 
> case then you would need to put the proper mail server, userid and 
> password into file mentioned, /etc/esmtprc, to make it all work.  Or, 
> you could go into /etc/smartmontools/smartd.conf and change the 
> configuration so it doesn't try to send emails.
>
> To check to see if esmtp is actually the MTA your system is configured 
> to use: "sudo alternatives --config mta"
>
> To confirm that there is a disk problem that smartd is trying to 
> notify you about: do "sudo smartctl --scan" to find the disk devices 
> smart knows about and then do "sudo smartctl -a /dev/sdX" for one of 
> the listed devices.

The only activated option in smartd.conf was

DEVICESCAN -H -m root -M exec /usr/libexec/smartmontools/smartdnotify -n 
standby,10,q

none of the email options were active but one could be hidden here.

Commented it out as I typically monitor the disks from the 
gnome-disk-utility application. Will do a boot to see.

Thanks David

[David King]

On 8/17/24 00:37, Robert McBroom via users wrote:
> On 8/16/24 11:00 PM, David King wrote:
> > On 8/16/24 11:32, Robert McBroom via users wrote:
> > > Boot process f40 system stops for a long time with a problem with 
> > > smartd. Seems to access the system drives and note that they are 
> > > SMART capable. The following entries are in the journal
> > >
> > > smartd[977]: Warning via /usr/libexec/smartmontools/smartdnotify to 
> > > root produced>>
> > >
> > > smartd[977]: No configuration file found at (null) or /etc/esmtprc
> > >
> > > After multiple entries
> > >
> > > smartd[977]: No configuration file found at (null) or /etc/esmtp
> > >
> > > The files referenced are not in /etc. Don't see such files on a f39 
> > > system
> > >
> > > What is the system looking to find and where can it be found.
> >
> > esmtp is a mail transfer agent (MTA).  Use "sudo dnf info esmtp" to 
> > see its Fedora package info.  I know that on Fedora smartd is 
> > configured by default to send e-mail when it detects a problem on a 
> > disk.  It may be that your system is configured to use esmtp to send 
> > mail and smartd has found a disk problem and is hanging when it tries 
> > to email you because esmtp is not configured properly. If that is the 
> > case then you would need to put the proper mail server, userid and 
> > password into file mentioned, /etc/esmtprc, to make it all work.  Or, 
> > you could go into /etc/smartmontools/smartd.conf and change the 
> > configuration so it doesn't try to send emails.
> >
> > To check to see if esmtp is actually the MTA your system is 
> > configured to use: "sudo alternatives --config mta"
> >
> > To confirm that there is a disk problem that smartd is trying to 
> > notify you about: do "sudo smartctl --scan" to find the disk devices 
> > smart knows about and then do "sudo smartctl -a /dev/sdX" for one of 
> > the listed devices.
>
> The only activated option in smartd.conf was
>
> DEVICESCAN -H -m root -M exec /usr/libexec/smartmontools/smartdnotify 
> -n standby,10,q
>
> none of the email options were active but one could be hidden here.
>
> Commented it out as I typically monitor the disks from the 
> gnome-disk-utility application. Will do a boot to see.
>
> Thanks David

Just checking ...

If you commented that line out entirely without adding something else 
then you have effectively disabled smartd.  If that's what you intended, 
well, ok then.  Otherwise ...

The part of that line that was resulting in e-mails being sent is the 
"-m root -M exec /usr/libexec/smartmontools/smartdnotify" part.  If you 
delete just that part then smartd will still health-check your disks but 
it won't try to tell you about what it finds unless you ask, i.e., with 
those "sudo smartctl -a /dev/sdX" commands I mentioned in my previous.

"man smartd.conf" explains all the options available but I'll grant you 
that it isn't real understandable for non-experts.  The comments in the 
distribution's default /etc/smartmontools/smartd.conf are maybe a bit 
more helpful.

[Iosif Fettich]

I'm curious about what tool[s] you use for "simply taking a report a
day for each disk and when
disks act up I see if the bad sectors count are rising on one of the disks".

[I do not agree with the 'less than useful' classification of smartd.
Did you really see situations where
 your just-look-at-the-bad-blocks strategy  did reveal some imminent
catastrophe but smartd did _not_?

[I was thinking about opening another thread for this, but stepped
back then again.]

Thank you!

În vin., 16 aug. 2024 la 19:21, Roger Heflin  a scris:
> Someone seems to have added it to setup a snmp config.   It is
> unlikely you want an snmp config/install, its only use is for external
> monitoring via the network (without ssh access) and is for the most
> part not being used much anymore.
>
> You might do a man smartd.conf and see if there is an option to
> disable snmp config completely.
>
> I also disable smartd because generally it is less than useful (I have
> had too many "your disk is going to fail soon" notifications where the
> disk stopped working >3 years later--so the warning was useless, I
> have also had disks fail that smartd did not ever report as failed).
>  Generally I view its reliability is so bad the tool is actually WORSE
> than useless since it scares you with incorrect warnings, and fails to
> report real (usually bad sector issues) correctly.
>
> I replace it with simply taking a report a day for each disk and when
> disks act up I see if the bad sectors count are rising on one of the
> disks.
>
> On Fri, Aug 16, 2024 at 10:33 AM Robert McBroom via users
>  wrote:
> > Boot process f40 system stops for a long time with a problem with smartd. Seems to access the system drives and note that they are SMART capable. The following entries are in the journal
> >
> > smartd[977]: Warning via /usr/libexec/smartmontools/smartdnotify to root produced>>
> >
> > smartd[977]: No configuration file found at (null) or /etc/esmtprc
> >
> > After multiple entries
> >
> > smartd[977]: No configuration file found at (null) or /etc/esmtp
> >
> > The files referenced are not in /etc. Don't see such files on a f39 system
> >
> > What is the system looking to find and where can it be found.
> >
> > --
> > _______________________________________________
> > users mailing list -- [e-mail]
> > To unsubscribe send an email to [e-mail]
> > Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives: https://lists.fedoraproject.org/archives/list/[e-mail]
> > Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
>
> --
> _______________________________________________
> users mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedoraproject.org/archives/list/[e-mail]
> Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

[Barry Scott]

> On 20 Aug 2024, at 17:04, Iosif Fettich  wrote:
>
> I'm curious about what tool[s] you use for "simply taking a report a
> day for each disk and when
> disks act up I see if the bad sectors count are rising on one of the disks".
>
> [I do not agree with the 'less than useful' classification of smartd.
> Did you really see situations where
> your just-look-at-the-bad-blocks strategy  did reveal some imminent
> catastrophe but smartd did _not_?
>
> [I was thinking about opening another thread for this, but stepped
> back then again.]

If its a HDD the interesting counter from smartctl are these two for me:

5 Reallocated_Sector_Ct   0x0033   100   100   010    Pre-fail  Always       -       0
196 Reallocated_Event_Count 0x0032   100   100   000    Old_age   Always       -       0

For an SSD I want to know hold much data has been written so that I can calculate
how long until the drives endurance is exceeded:

241 Host_Writes_32MiB       0x0032   100   100   000    Old_age   Always       -       351959

For all the SSD's I own I know the endurance figure.
I will not buy an SSD that the manufacturer does not publish the endurance for.

Barry
> Thank you!
>
> În vin., 16 aug. 2024 la 19:21, Roger Heflin  a scris:
> > Someone seems to have added it to setup a snmp config.   It is
> > unlikely you want an snmp config/install, its only use is for external
> > monitoring via the network (without ssh access) and is for the most
> > part not being used much anymore.
> >
> > You might do a man smartd.conf and see if there is an option to
> > disable snmp config completely.
> >
> > I also disable smartd because generally it is less than useful (I have
> > had too many "your disk is going to fail soon" notifications where the
> > disk stopped working >3 years later--so the warning was useless, I
> > have also had disks fail that smartd did not ever report as failed).
> > Generally I view its reliability is so bad the tool is actually WORSE
> > than useless since it scares you with incorrect warnings, and fails to
> > report real (usually bad sector issues) correctly.
> >
> > I replace it with simply taking a report a day for each disk and when
> > disks act up I see if the bad sectors count are rising on one of the
> > disks.
> >
> > On Fri, Aug 16, 2024 at 10:33 AM Robert McBroom via users
> >  wrote:
> > > Boot process f40 system stops for a long time with a problem with smartd. Seems to access the system drives and note that they are SMART capable. The following entries are in the journal
> > >
> > > smartd[977]: Warning via /usr/libexec/smartmontools/smartdnotify to root produced>>
> > >
> > > smartd[977]: No configuration file found at (null) or /etc/esmtprc
> > >
> > > After multiple entries
> > >
> > > smartd[977]: No configuration file found at (null) or /etc/esmtp
> > >
> > > The files referenced are not in /etc. Don't see such files on a f39 system
> > >
> > > What is the system looking to find and where can it be found.
> > >
> > > --
> > > _______________________________________________
> > > users mailing list -- [e-mail]
> > > To unsubscribe send an email to [e-mail]
> > > Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > > List Archives: https://lists.fedoraproject.org/archives/list/[e-mail]
> > > Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
> >
> > --
> > _______________________________________________
> > users mailing list -- [e-mail]
> > To unsubscribe send an email to [e-mail]
> > Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives: https://lists.fedoraproject.org/archives/list/[e-mail]
> > Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
>
> -- 
> _______________________________________________
> users mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedoraproject.org/archives/list/[e-mail]
> Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

[Robert McBroom]

On 8/17/24 9:20 AM, David King wrote:
> On 8/17/24 00:37, Robert McBroom via users wrote:
> > On 8/16/24 11:00 PM, David King wrote:
> > > On 8/16/24 11:32, Robert McBroom via users wrote:
> > > > Boot process f40 system stops for a long time with a problem with 
> > > > smartd. Seems to access the system drives and note that they are 
> > > > SMART capable. The following entries are in the journal
> > > >
> > > > smartd[977]: Warning via /usr/libexec/smartmontools/smartdnotify to 
> > > > root produced>>
> > > >
> > > > smartd[977]: No configuration file found at (null) or /etc/esmtprc
> > > >
> > > > After multiple entries
> > > >
> > > > smartd[977]: No configuration file found at (null) or /etc/esmtp
> > > >
> > > > The files referenced are not in /etc. Don't see such files on a f39 
> > > > system
> > > >
> > > > What is the system looking to find and where can it be found.
> > >
> > > esmtp is a mail transfer agent (MTA).  Use "sudo dnf info esmtp" to 
> > > see its Fedora package info.  I know that on Fedora smartd is 
> > > configured by default to send e-mail when it detects a problem on a 
> > > disk.  It may be that your system is configured to use esmtp to send 
> > > mail and smartd has found a disk problem and is hanging when it 
> > > tries to email you because esmtp is not configured properly. If that 
> > > is the case then you would need to put the proper mail server, 
> > > userid and password into file mentioned, /etc/esmtprc, to make it 
> > > all work.  Or, you could go into /etc/smartmontools/smartd.conf and 
> > > change the configuration so it doesn't try to send emails.
> > >
> > > To check to see if esmtp is actually the MTA your system is 
> > > configured to use: "sudo alternatives --config mta"
> > >
> > > To confirm that there is a disk problem that smartd is trying to 
> > > notify you about: do "sudo smartctl --scan" to find the disk devices 
> > > smart knows about and then do "sudo smartctl -a /dev/sdX" for one of 
> > > the listed devices.
> >
> > The only activated option in smartd.conf was
> >
> > DEVICESCAN -H -m root -M exec /usr/libexec/smartmontools/smartdnotify 
> > -n standby,10,q
> >
> > none of the email options were active but one could be hidden here.
> >
> > Commented it out as I typically monitor the disks from the 
> > gnome-disk-utility application. Will do a boot to see.
> >
> > Thanks David
>
> Just checking ...
>
> If you commented that line out entirely without adding something else 
> then you have effectively disabled smartd.  If that's what you 
> intended, well, ok then.  Otherwise ...
>
> The part of that line that was resulting in e-mails being sent is the 
> "-m root -M exec /usr/libexec/smartmontools/smartdnotify" part.  If 
> you delete just that part then smartd will still health-check your 
> disks but it won't try to tell you about what it finds unless you ask, 
> i.e., with those "sudo smartctl -a /dev/sdX" commands I mentioned in 
> my previous.
>
> "man smartd.conf" explains all the options available but I'll grant 
> you that it isn't real understandable for non-experts.  The comments 
> in the distribution's default /etc/smartmontools/smartd.conf are maybe 
> a bit more helpful.

Smartd is still available on demand just not always running. The 
gnome-disk-utility shows all the disks on the system and runs the SMART 
data and self tests on demand. I do have a disk that is showing quite a 
high read error rate which was probably what the mail warning was about. 
I don't use sendmail so there was nothing there for the mail. There are 
four bad sectors that have never triggered the reallocate function.