Debconf question during install should ask if smartd should be started automatically, like in hddtemp package

[Manuel López-Ibáñez]

It's not easy to find how to enable hard disk S.M.A.R.T. monitoring for ordinary computer administrator, especially for home computer user. Almost nobody knows, that he should read /usr/share/doc/smartmontools/README.Debian, where is information, that after installation S.M.A.R.T. monitoring isn't working and file /etc/default/smartmontools should be modified for having working S.M.A.R.T. monitoring...

So, there should be at least debconf question, asked at package's install time - look for example hddtemp package, which does very similar job - monitors hard disks temperature.
I think we simply could look at hddtemp source package's debian folder and steal needed scripts and debconf templates.

It seems most users think, that after installation of smartmontools package S.M.A.R.T. monitoring works on their system, because in smartmontools package's description there are no warning, that monitoring doesn't starts automatically - there is just nice info, that S.M.A.R.T. monitoring should be on any Linux system:

control and monitor storage systems using S.M.A.R.T.
The smartmontools package contains two utility programs (smartctl and smartd) to control and monitor storage systems using the Self-Monitoring, Analysis and Reporting Technology System (S.M.A.R.T.) built into most modern ATA and SCSI hard disks. It should run on any modern Linux system.

Majority of users simply installs smartmontools and don't know, that this isn't enough for enabling S.M.A.R.T. monitoring, additionally they need to:

1. read the documentation in /usr/share/doc/smartmontools/README.Debian
2. uncomment some lines in /etc/default/smartmontools
3. try to start smartd (invoke-rc.d smartd start)
4. read the log files to find if smartd was started
5. edit /etc/smartd.conf if there are any errors in log files.

These steps is just completely unintuitive (it took me a lot of google to find out and from the forums, I am not the only one). Yet, I would argue about the usefulness of /etc/default/smartmontools configuration file at all when one can simply not start the start-up script on boot.

[Guido Günther (agx)]

tags 204613 +wontfix
Thanks,

On Fri, Aug 08, 2003 at 11:37:31AM -0700, Mike Fedyk wrote:
> Although it's easy to modify /etc/default/smartmontools it should be asked
> at install time though.
Well, this would involve running smartd with DEVICESCAN the first time
which clutters people's syslog and might cause problems. I'd prefer to
let people read the docs before starting the daemon. (In the not so near
future) I plan to implement DEVICESCAN as a seperate tool that is able
to write out smartd.conf, once this is there (and Bruce doesn't object
to such a tool) making /e/d/smartmontools debconf handeld will be easy.
Regards,
 -- Guido

[Bruce Allen (ballen)]

> On Fri, Aug 08, 2003 at 11:37:31AM -0700, Mike Fedyk wrote:
> > Although it's easy to modify /etc/default/smartmontools it should be asked
> > at install time though.

> Well, this would involve running smartd with DEVICESCAN the first time
> which clutters people's syslog and might cause problems. I'd prefer to
> let people read the docs before starting the daemon.

I also think that's the right approach, since there are some devices that
can apparently cause system hangs when probed by smartmontools.

> (In the not so near
> future) I plan to implement DEVICESCAN as a seperate tool that is able
> to write out smartd.conf, once this is there (and Bruce doesn't object
> to such a tool) making /e/d/smartmontools debconf handeld will be easy.

There are a few approaches that one could use for this:
(1) Scan hardware database (/etc/sysconfig/hwconf on Redhat, for
    example) and use a pearl/python script to make /etc/smartd.conf

(2) Add a -o filename option to smartd. This option makes it run silently
in the foreground, construct a device list, probe devices (once) for SMART
capabilities, print device list in correct format, and then exit. We
could make smartd set itself an alarm and kill signal at the start so
that it would be guaranteed to exit after (say) 20 seconds.

Guido, if you like option 2, everything is already in place, with the
exception of a routine to print the output file. This is nice because it
keeps us from having to maintain a separate tool, and evolves in parallel
with smartd.

Cheers,
 Bruce

[Guido Günther (agx)]

On Tue, Aug 12, 2003 at 02:50:08PM -0500, Bruce Allen wrote:
> There are a few approaches that one could use for this:
> (1) Scan hardware database (/etc/sysconfig/hwconf on Redhat, for
> example) and use a pearl/python script to make /etc/smartd.conf
Debian lacks a hw database at the moment. Are hot pluggable devices
listed there too?

> (2) Add a -o filename option to smartd. This option makes it run silently
> in the foreground, construct a device list, probe devices (once) for SMART
> capabilities, print device list in correct format, and then exit. We
> could make smartd set itself an alarm and kill signal at the start so
> that it would be guaranteed to exit after (say) 20 seconds.
This sounds very good.

> Guido, if you like option 2, everything is already in place, with the
> exception of a routine to print the output file. This is nice because it
> keeps us from having to maintain a separate tool, and evolves in parallel
> with smartd.
I've put this on my TODO list but I don't think I'll find the time to
look into this in the very near future.
 -- Guido

[Bruce Allen (ballen)]

> > There are a few approaches that one could use for this:
> > (1) Scan hardware database (/etc/sysconfig/hwconf on Redhat, for
> > example) and use a pearl/python script to make /etc/smartd.conf

> Debian lacks a hw database at the moment. Are hot pluggable devices
> listed there too?

Interesting -- I had some email exchange with Arjan van de Ven about how
to improve the smartmontools packaging in redhat. He thought that every
major distribution has some type of hardware database engine.

I don't know if the redhat database has hot pluggable devices -- but I'll
find out.

I've been working on the internal structure of smartd quite a lot during
the past days - in particular to make all the important internal
structures dynamically allocated/deallocated. So it should make it easy
to accomodate a future where we could actually track devices as they are
added and removed without having to even restart smartd.

> > (2) Add a -o filename option to smartd. This option makes it run silently
> > in the foreground, construct a device list, probe devices (once) for SMART
> > capabilities, print device list in correct format, and then exit. We
> > could make smartd set itself an alarm and kill signal at the start so
> > that it would be guaranteed to exit after (say) 20 seconds.

> This sounds very good.

It's quite easy -- in fact documenting it is harder than writing the code.

> > Guido, if you like option 2, everything is already in place, with the
> > exception of a routine to print the output file. This is nice because it
> > keeps us from having to maintain a separate tool, and evolves in parallel
> > with smartd.

> I've put this on my TODO list but I don't think I'll find the time to
> look into this in the very near future.

Tell me if you want to do it. Or tell me if you think you'd use it -
since this may be the motive that I need to push me to add it myself!

Cheers,
 Bruce

[Guido Günther (agx)]

Hi Bruce,
On Wed, Aug 13, 2003 at 05:31:07AM -0500, Bruce Allen wrote:
> > > Guido, if you like option 2, everything is already in place, with the
> > > exception of a routine to print the output file. This is nice because it
> > > keeps us from having to maintain a separate tool, and evolves in parallel
> > > with smartd.
>
> > I've put this on my TODO list but I don't think I'll find the time to
> > look into this in the very near future.
>
> Tell me if you want to do it. Or tell me if you think you'd use it -
> since this may be the motive that I need to push me to add it myself!
This only makes sense if I change the debian packaging quiet a bit. When
I do this I can add the function to write out smartd.conf too.
Regards,
 -- Guido

[Bruce Allen (ballen)]

> > > > Guido, if you like option 2, everything is already in place, with the
> > > > exception of a routine to print the output file. This is nice because it
> > > > keeps us from having to maintain a separate tool, and evolves in parallel
> > > > with smartd.
> >
> > > I've put this on my TODO list but I don't think I'll find the time to
> > > look into this in the very near future.
> >
> > Tell me if you want to do it. Or tell me if you think you'd use it -
> > since this may be the motive that I need to push me to add it myself!
>
> This only makes sense if I change the debian packaging quiet a bit. When
> I do this I can add the function to write out smartd.conf too.

Tell me when the time comes and I'll either do it or help you do it.

Cheers,
 Bruce

[Guido Günther (agx)]

# Automatically generated email from bts, devscripts version 2.7.95.1
merge 246615 204613

[Guido Günther (agx)]

# Automatically generated email from bts, devscripts version 2.7.95.1
unmerge 246615

[Mike Fedyk (mfedyk)]

submitter 169819 !
submitter 173472 !
submitter 173701 !
submitter 192078 !
submitter 192091 !
submitter 192395 !
submitter 202507 !
submitter 213318 !
submitter 213321 !
submitter 213323 !
submitter 213326 !
submitter 218511 !
submitter 218515 !
submitter 219205 !
submitter 224847 !
submitter 225619 !
submitter 228021 !
submitter 232955 !
submitter 235038 !
submitter 236352 !
submitter 238766 !
submitter 267006 !
submitter 271099 !
submitter 272034 !
submitter 131365 !
submitter 163876 !
submitter 164350 !
submitter 193075 !
submitter 196288 !
submitter 218393 !
submitter 218477 !
submitter 235708 !
submitter 237547 !
submitter 163362 !
submitter 163867 !
submitter 170864 !
submitter 174412 !
submitter 179009 !
submitter 193079 !
submitter 200811 !
submitter 202509 !
submitter 202625 !
submitter 203235 !
submitter 203241 !
submitter 204613 !
submitter 211853 !
submitter 213386 !
submitter 213391 !
submitter 213511 !
submitter 213517 !
submitter 220341 !
submitter 220487 !
submitter 222948 !
submitter 225574 !
submitter 235710 !
submitter 268999 !
submitter 269869 !
submitter 271090 !
submitter 184818 !
submitter 209261 !
submitter 222683 !
submitter 202000 !
submitter 195617 !
submitter 210147 !
submitter 220695 !
submitter 231480 !
submitter 201793 !
submitter 219670 !
submitter 170098 !

[Manuel López-Ibáñez (manuellopezibanez)]

To enabled SMART monitoring tool, you need to

* install the package
* run that start-up script on boot
* AND uncomment some lines in /etc/default/smartmontools

The last step is just too much and completely unintuitive (it took me a lot of google to find out and from the forums, I am not the only one). If any, those lines should be uncommented by default. Yet, I would argue about the usefulness of that configuration file at all when one can simply not start the start-up script on boot.

[Mantas Kriaučiūnas (mantas)]

This bug is againts smartmontools, not smart package manager

[xteejx (xteejx-deactivatedaccount)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. You reported this bug a while ago and there hasn't been any activity in it recently. We were wondering if this is still an issue for you. Can you try with the latest Ubuntu release? Thanks in advance.

[Jarl (jarl-dk)]

This bug is still an issue in Jaunty with latest updates. See bug 390569.

I hope you will fix this.

[xteejx (xteejx-deactivatedaccount)]

Marking Confirmed, Wishlist. This isnt so much a bug as a request for a feature to be implemented. In this instance, for smart to be enabled at boot. Thank you.