> 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.
> On Fri, Aug 08, 2003 at 11:37:31AM -0700, Mike Fedyk wrote: smartmontools it should be asked
> > Although it's easy to modify /etc/default/
> > 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: /hwconf on Redhat, for
(1) Scan hardware database (/etc/sysconfig
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