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

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

> 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

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

> > 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

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

> > > > 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

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

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

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 !