S.M.A.R.T. Monitoring Tools

David K. wrote:
> Please find attached a simple patch to the startup script for smartd
> that allows a configuration file in /etc/sysconfig to control the
> initial command line flags to smartd.   This has proven very useful
> with our setup.

This is an interesting way to solve the same problem I was trying to
solve.  My patch (not yet released) basically makes some of the options
normally set through cmd line flags able to be set via the
/etc/smartd.conf file.  By doing that, I introduce the notion of
"global" options into the smartd.conf file, whereas now only drives are
dealt with.  Your solution is simpler but it requires another config file.

I wonder what is preferable to the maintainers?
Brett

> > Please find attached a simple patch to the startup script for smartd
> > that allows a configuration file in /etc/sysconfig to control the
> > initial command line flags to smartd.   This has proven very useful
> > with our setup.
> 
> This is an interesting way to solve the same problem I was trying to
> solve.  My patch (not yet released) basically makes some of the
> options normally set through cmd line flags able to be set via the
> /etc/smartd.conf file.  By doing that, I introduce the notion of
> "global" options into the smartd.conf file, whereas now only drives
> are dealt with.  Your solution is simpler but it requires another
> config file.
> 
> I wonder what is preferable to the maintainers?

I'm not sure -- with this email I'm asking.

The original idea with smartd was to have options that apply to all drives
be on the command line, and to have the options that apply 'drive by
drive' live in smartd.conf.  Normally the command-line is accessible in
the init script that starts smartd, and (at least with Redhat/Fedora) the
normal way to put these command-line options into a file is to use a file
in /etc/sysconfig/ to set their values.

So I personally like the idea of having:
if [ -f /etc/sysconfig/smartd ]; then
   . /etc/sysconfig/smard
fi

in the smartd init script, mostly because it simplifies smartd and saves
the burden of documenting/maintaining yet another file.

But I'm open to other opinions about this.  I'm curious what is done on
Debian, for example.

Cheers,
	Bruce

On Tue, Mar 30, 2004 at 10:26:22AM -0600, Bruce Allen wrote:
> So I personally like the idea of having:
> if [ -f /etc/sysconfig/smartd ]; then
>    . /etc/sysconfig/smard
> fi
Nice. We're using something like this in Debian for some time (it's
called /etc/default/smartmontools (this is what debian uses for these
kind of things, need to ckeck what FHS says about this). I'd be great if
we could agree on the same option names. We currently have this default
skript:

# Defaults for smartmontools initscript (/etc/init.d/smartmontools)
# This is a POSIX shell fragment

# list of devices you want to explicitly enable S.M.A.R.T. for
# not needed if the device is monitored by smartd
#enable_smart="/dev/hda /dev/hdb"

# uncomment to start smartd on system startup
#start_smartd=yes

# uncomment to pass additional options to smartd on startup
#smartd_opts="--interval=3600"

Does this look reasonable for other distributions too?
Cheers,
 -- Guido

On Thu, 1 Apr 2004, Guido Guenther wrote:

> On Tue, Mar 30, 2004 at 10:26:22AM -0600, Bruce Allen wrote:
> > So I personally like the idea of having:
> > if [ -f /etc/sysconfig/smartd ]; then
> >    . /etc/sysconfig/smard
> > fi
> Nice. We're using something like this in Debian for some time (it's
> called /etc/default/smartmontools (this is what debian uses for these
> kind of things, need to ckeck what FHS says about this).

FHS says nothing about /etc/sysconfig.

-- 
http://www.pervalidus.net/contact.html

> On Tue, Mar 30, 2004 at 10:26:22AM -0600, Bruce Allen wrote:
> > So I personally like the idea of having:
> > if [ -f /etc/sysconfig/smartd ]; then
> >    . /etc/sysconfig/smard
> > fi

> Nice. We're using something like this in Debian for some time (it's
> called /etc/default/smartmontools (this is what debian uses for these
> kind of things, need to ckeck what FHS says about this). I'd be great if
> we could agree on the same option names. We currently have this default
> skript:
> # Defaults for smartmontools initscript (/etc/init.d/smartmontools)
> # This is a POSIX shell fragment
> 
> # list of devices you want to explicitly enable S.M.A.R.T. for
> # not needed if the device is monitored by smartd
> #enable_smart="/dev/hda /dev/hdb"
> 
> # uncomment to start smartd on system startup
> #start_smartd=yes
> 
> # uncomment to pass additional options to smartd on startup
> #smartd_opts="--interval=3600"
> 
> Does this look reasonable for other distributions too?

Yes.

I think that the 'enable_smart' part might not be needed/used by other
distributions (I'm not sure what it does) but probably no harm having it
there.

By the way, I'd suggest that for things like smartd_opts="--interval=3600"
we make the commented default values agree with the package default values
(in this case --interval=1800).

Guido -- can you take responsibility for choosing option and file names in
a way that's consistent with FHS and putting it into our 'unified' init
script.  I suspect that the biggest issue is the /etc/sysconfig file name.  
I'd be happy with any of:
 smart
 smartd
 smartmontools
and since Redhat/Fedora don't have these files yet, we have freedom to
change the name...

Cheers,
	Bruce

> > > On Tue, Mar 30, 2004 at 10:26:22AM -0600, Bruce Allen wrote:
> > > Does this look reasonable for other distributions too?
> > Yes.
> 
> /etc/sysconfig doesn't.

OK, let's make a list of where different distribution put these
things. Please add on to this list and resend

Redhat/Fedora: /etc/sysconfig/
Debian:
Mandrake:
Slackware:
Gentoo:
SuSE:
Connectiva:
FHS:
Others?

Bruce

On Thu, 1 Apr 2004, Bruce Allen wrote:

> > > > On Tue, Mar 30, 2004 at 10:26:22AM -0600, Bruce Allen wrote:
> > > > Does this look reasonable for other distributions too?
> > > Yes.
> >
> > /etc/sysconfig doesn't.
>
> OK, let's make a list of where different distribution put these
> things. Please add on to this list and resend

> Slackware:

Nothing. Adding various directories to /etc and not being
compliant with the FHS was always a Red Hat thing, later
mimiced by other distributions.

> FHS: "/usr/share : Architecture-independent data"

/usr/share : Architecture-independent data Purpose

The /usr/share hierarchy is for all read-only architecture
independent data files. [30]

This hierarchy is intended to be shareable among all
architecture platforms of a given OS; thus, for example, a site
with i386, Alpha, and PPC platforms might maintain a single
/usr/share directory that is centrally-mounted. Note, however,
that /usr/share is generally not intended to be shared by
different OSes or by different releases of the same OS.

Any program or package which contains or requires data that
doesn't need to be modified should store that data in
/usr/share (or /usr/local/share, if installed locally). It is
recommended that a subdirectory be used in /usr/share for this
purpose.

Game data stored in /usr/share/games must be purely static
data. Any modifiable files, such as score files, game play
logs, and so forth, should be placed in / var/games.

/usr/share/misc : Miscellaneous architecture-independent data

This directory contains miscellaneous architecture-independent
files which don't require a separate subdirectory under
/usr/share.

[22] Miscellaneous architecture-independent
application-specific static files and subdirectories must be
placed in /usr/share.

[30] Much of this data originally lived in /usr (man, doc) or
/usr/lib (dict, terminfo, zoneinfo).

-- 
http://www.pervalidus.net/contact.html

> Adding various directories to /etc and not being compliant with the
> FHS was always a Red Hat thing, later mimiced by other distributions.

Please, I'd like to know where the other distributions put these files.

Bruce

On Thu, 1 Apr 2004, Fr=E9d=E9ric L. W. Meunier wrote:

> The /usr/share hierarchy is for all read-only architecture
> independent data files. [30]
>
> Any program or package which contains or requires data that
> doesn't need to be modified should store that data in
> /usr/share (or /usr/local/share, if installed locally). It is
> recommended that a subdirectory be used in /usr/share for this
> purpose.
>
> Game data stored in /usr/share/games must be purely static
> data. Any modifiable files, such as score files, game play
> logs, and so forth, should be placed in / var/games.

Modifiable. /var what then ? /var/lib ?

--=20
http://www.pervalidus.net/contact.html

On Thu, 1 Apr 2004, Bruce Allen wrote:

> > Adding various directories to /etc and not being compliant with the
> > FHS was always a Red Hat thing, later mimiced by other distributions.
>
> Please, I'd like to know where the other distributions put these files.

I don't know, but it's the truth. And if all but one don't use
/etc/sysconfig, it shouldn't be enabled by default. Not to
mention not being FHS compliant.

But if you want to create an /etc/smartd or /etc/smartmontools,
I don't see it as a problem.

-- 
http://www.pervalidus.net/contact.html

> > > Adding various directories to /etc and not being compliant with the
> > > FHS was always a Red Hat thing, later mimiced by other distributions.
> >
> > Please, I'd like to know where the other distributions put these files.
> 
> I don't know, but it's the truth. And if all but one don't use
> /etc/sysconfig, it shouldn't be enabled by default. Not to
> mention not being FHS compliant.
> 
> But if you want to create an /etc/smartd or /etc/smartmontools,
> I don't see it as a problem.

I'm waiting to hear what Guido says...

Bruce

Bruce Allen wrote:
> OK, let's make a list of where different distribution put these
> things. Please add on to this list and resend
> 
> Redhat/Fedora: /etc/sysconfig/
> Debian:
> Mandrake:
> Slackware:
> Gentoo:
> SuSE: /etc/sysconfig/
> Connectiva:
> FHS:
> Others?

On Thu, Apr 01, 2004 at 03:04:47PM -0600, Bruce Allen wrote:
> I think that the 'enable_smart' part might not be needed/used by other
> distributions (I'm not sure what it does) but probably no harm having it
> there.

This is what enable_smart does:
enable_smart() {
  echo -n "Enabling S.M.A.R.T. for:"
  for device in $enable_smart; do
        echo -n " $device"
        $SMARTCTL --quietmode=3Derrorsonly --smart=3Don $device || \
            { echo -n "(failed)"; RET=3D2; }
  done
  echo "."
}

> By the way, I'd suggest that for things like smartd_opts=3D"--interval=3D=
3600"
> we make the commented default values agree with the package default values
> (in this case --interval=3D1800).
O.k., fine I'll do that.

> Guido -- can you take responsibility for choosing option and file names in
> a way that's consistent with FHS and putting it into our 'unified' init
> script.  I suspect that the biggest issue is the /etc/sysconfig file name=
=2E =20
> I'd be happy with any of:
>  smart
>  smartd
>  smartmontools
> and since Redhat/Fedora don't have these files yet, we have freedom to
> change the name...
O.k., I'll have a look.
 -- Guido

On Thu, Apr 01, 2004 at 06:17:03PM -0300, Fr=E9d=E9ric L. W. Meunier wrote:
> If you want to add something for all distributions, use
> /usr/share/smartmontools (I don't see a better place) or
> something, but not /etc/sysconfig. Or if you insist, make it
> disabled by default.
I'd prefer to have all configuration data in /etc. It would probably
make sense to have the _format_ of the configuration file the same
across all distributions but not the _location_.
 -- Guido

On Thu, Apr 01, 2004 at 03:31:03PM -0600, Bruce Allen wrote:
> Redhat/Fedora: /etc/sysconfig/
> Debian:
/etc/default/
> Mandrake:
> Slackware:
> Gentoo:
> SuSE:
Seems to have both: /etc/default and /etc/sysconfig
> Connectiva:
> FHS:
> Others?
>=20
> Bruce

On Fri, 2 Apr 2004, Guido Guenther wrote:

> On Thu, Apr 01, 2004 at 06:17:03PM -0300, Fr=E9d=E9ric L. W. Meunier wrot=
e:
> > If you want to add something for all distributions, use
> > /usr/share/smartmontools (I don't see a better place) or
> > something, but not /etc/sysconfig. Or if you insist, make it
> > disabled by default.

> I'd prefer to have all configuration data in /etc. It would probably
> make sense to have the _format_ of the configuration file the same
> across all distributions but not the _location_.

I have a suggestion along these lines that might simplify our lives.  I am
getting cold feet at the idea of addding another configuration file which
needs to be documented and maintained, and whose installation location
will have to be documented and maintain with yet another switch to
=2E/configure.  While I appreciate the desire to be flexible, I think it's
important to try and keep the package as simple as we possibly can, both
for maintainers and users.

One alternative is to simply put this global information into smartd.conf. =
=20
Then there is no additional file or man page to maintain, and the problem
is solved.  But this seems a bit nutty since we can accomplish what's
needed with a few shell variables.  Bloating smartd with additional
parsing and error handling is inefficient.

I think I might prefer a simpler alternative. We currently distribute a
start-up script (smartd.initd.in) with smartmontools which supports many
distributions. Why don't we simply do the following?  At the beginning of
the script, set a number of standard variables, like this:

SMARTD_INTERVAL=3D1800
SMARTD_ANOTHER_ARG=3DANOTHER_VAL
=2E..

Then, in the distribution-specific parts of the script, have:


# Redhat
if [ -f /etc/sysconfig/smartd ] ; then
   . /etc/sysconfig/smartd
fi

# Debian
if [ -f /etc/defaults/smartmontools ] ; then
   . /etc/defaults/smartmontools
fi

Within those files, users/distribution maintainers are welcome to
over-ride the default values of the variables, set at the top of the init
script.

Finally, in each place where smartd is called in the script, pass the
arguments explicitly.  So, for example,

            daemon /usr/sbin/smartd

becomes
            daemon /usr/sbin/smartd --interval $SMARTD_INTERVAL  --another_=
option $SMARTD_ANOTHER_VARIABLE

Advantages:
- simplicity and clarity
- some minor edits to smartd.initd.in are all that's needed
- each distribution has the file in its standard place
- if the file is not present, no problem, you just get
  the standard defaults
- no additional ./configure script options to maintain.

Disadvanges:
  I don't see any.

Cheers,
=09Bruce

> This is what enable_smart does:
> enable_smart() {
>   echo -n "Enabling S.M.A.R.T. for:"
>   for device in $enable_smart; do
>         echo -n " $device"
>         $SMARTCTL --quietmode=errorsonly --smart=on $device || \
>             { echo -n "(failed)"; RET=2; }
>   done
>   echo "."
> }

OK, this might be necessary for SCSI devices (smartd automatically enable
SMART on ATA devices).  You might want to add a comment to that effect.
[Doug is opposed to smartd automatically enabling SMART for SCSI devices.]

> > By the way, I'd suggest that for things like smartd_opts="--interval=3600"
> > we make the commented default values agree with the package default values
> > (in this case --interval=1800).
> O.k., fine I'll do that.
> 
> > Guido -- can you take responsibility for choosing option and file names in
> > a way that's consistent with FHS and putting it into our 'unified' init
> > script.  I suspect that the biggest issue is the /etc/sysconfig file name.  
> > I'd be happy with any of:
> >  smart
> >  smartd
> >  smartmontools
> > and since Redhat/Fedora don't have these files yet, we have freedom to
> > change the name...
> O.k., I'll have a look.

As you see from my last email, I'm backing away from this 'unified file
location.' Right now I'd prefer to define these standard variables in
smartd.initd.in and then have distribution specific file includes to
over-ride them if desired by the distribution/user.

Cheers,
	Bruce

On Fri, Apr 02, 2004 at 07:07:06AM -0600, Bruce Allen wrote:
> Advantages:
> - simplicity and clarity
> - some minor edits to smartd.initd.in are all that's needed
> - each distribution has the file in its standard place
> - if the file is not present, no problem, you just get
>   the standard defaults
> - no additional ./configure script options to maintain.
>=20
> Disadvanges:
>   I don't see any.
Distributors want to keep "variables" and scripts in different files.
This makes it much easier to update the script but preserve user
settings. Alternative suggestion:
We only agree on variable _naming_. If these get set by a configuration
file in /etc/default, /etc/sysconfig or in smartd.initd itself won't
matter (smartd.init could even check for the existence of additional
configuration files). Every distributor will adopt it's own thing
anyway. The script that comes with the smartmontools .tar.gz will set
variables as you suggested. The rest is up to the distribution.
Cheers,
 -- Guido

On Fri, Apr 02, 2004 at 07:10:33AM -0600, Bruce Allen wrote:
> > This is what enable_smart does:
> > enable_smart() {
> >   echo -n "Enabling S.M.A.R.T. for:"
> >   for device in $enable_smart; do
> >         echo -n " $device"
> >         $SMARTCTL --quietmode=3Derrorsonly --smart=3Don $device || \
> >             { echo -n "(failed)"; RET=3D2; }
> >   done
> >   echo "."
> > }
>=20
> OK, this might be necessary for SCSI devices (smartd automatically enable
> SMART on ATA devices).  You might want to add a comment to that effect.
> [Doug is opposed to smartd automatically enabling SMART for SCSI devices.]
The current Debian configuration says:

# list of devices you want to explicitly enable S.M.A.R.T. for
# not needed if the device is monitored by smartd

so you think:

# List of devices you want to explicitly enable S.M.A.R.T. for
# Not needed if the device is a ATA device and monitored by smartd
# But note that smartd doesn't enable S.M.A.R.T on SCSI devices
# automatically
smart_enable=3D...

would be better?

> As you see from my last email, I'm backing away from this 'unified file
> location.' Right now I'd prefer to define these standard variables in
> smartd.initd.in and then have distribution specific file includes to
> over-ride them if desired by the distribution/user.
Fine. We could try to agree on a sensible naming though.
 -- Guido

> settings. Alternative suggestion:
> We only agree on variable _naming_. If these get set by a configuration
> file in /etc/default, /etc/sysconfig or in smartd.initd itself won't
> matter (smartd.init could even check for the existence of additional
> configuration files). Every distributor will adopt it's own thing
> anyway. The script that comes with the smartmontools .tar.gz will set
> variables as you suggested. The rest is up to the distribution.

This is exactly what I had in mind!

smartd.initd sets the various variables, that have the same names for ALL
distributions.

Each distribution section checks for existence of an additional config
file in its preferred location, and resets the variables from that file,
if desired.

Cheers,
	Bruce

> so you think:
> 
> # List of devices you want to explicitly enable S.M.A.R.T. for
> # Not needed if the device is a ATA device and monitored by smartd
> # But note that smartd doesn't enable S.M.A.R.T on SCSI devices
> # automatically
> smart_enable=...
> 
> would be better?

Yes
 
> > As you see from my last email, I'm backing away from this 'unified file
> > location.' Right now I'd prefer to define these standard variables in
> > smartd.initd.in and then have distribution specific file includes to
> > over-ride them if desired by the distribution/user.
> Fine. We could try to agree on a sensible naming though.

Absolutely!

Guido, will you take charge of this?  In other words, edit smartd.initd.in
in a sensible way?

I don't think you need to search for consensus first -- if people don't
like your choices we can talk it through on the mailing list and then
check modifications into CVS later.

Cheers,
	Bruce

On Thu, 1 Apr 2004, Bruce Allen wrote:

> > On Tue, Mar 30, 2004 at 10:26:22AM -0600, Bruce Allen wrote:
> > Does this look reasonable for other distributions too?
>
> Yes.

/etc/sysconfig doesn't.

> I suspect that the biggest issue is the /etc/sysconfig file
> name.

No, the biggest is /etc/sysconfig.

> I'd be happy with any of:
>  smart
>  smartd
>  smartmontools
> and since Redhat/Fedora don't have these files yet, we have freedom to
> change the name...

If you want to add something for all distributions, use
/usr/share/smartmontools (I don't see a better place) or
something, but not /etc/sysconfig. Or if you insist, make it
disabled by default.

-- 
http://www.pervalidus.net/contact.html

> > Absolutely!
> > 
> > Guido, will you take charge of this?  In other words, edit smartd.initd.in
> > in a sensible way?

> O.k. what about the attached changes? Redhat is missing since I'm not
> sure about the "daemon" call. I assume I can just append the arguments?

The changes look fine -- please go ahead and check them into CVS.  I think
you can just append the arguments to the daemon call -- in any case I'll
take responsibility for testing it and fixing it if needed.

Cheers,
	Bruce

Guido Guenther wrote:
> O.k. what about the attached changes? Redhat is missing since I'm not
> sure about the "daemon" call. I assume I can just append the arguments?

My only issue with the below is that 99.9% of the config files in SuSE 
are in /etc/sysconfig.  There are ~69 conf. files there and 1 conf. file 
in /etc/default (on my SuSE 9.0 pro system).  Why not stick to the 
distro's convention since you're doing distribution specific code anyway?

BR

> 
> @@ -128,6 +136,8 @@ elif [ -f /etc/SuSE-release ] ; then
>      # Existence of config file is optional
>      SMARTD_CONFIG=/etc/smartd.conf
>  
> +# source configuration file
> +    [ -r /etc/default/smartmontools ] && . /etc/default/smartmontools

On Mon, Apr 05, 2004 at 12:22:29AM -0400, Brett Russ wrote:
> My only issue with the below is that 99.9% of the config files in SuSE=20
> are in /etc/sysconfig.  There are ~69 conf. files there and 1 conf. file=
=20
> in /etc/default (on my SuSE 9.0 pro system).  Why not stick to the=20
> distro's convention since you're doing distribution specific code anyway?
SuSE is well known for starting moves from one subdir to another with
just some files. Are you sure /etc/sysconfig will stay the default? It
looks to me that more and more files are moving to /etc/default, but
this could be wrong since I didn't follow SuSE development closely
recently.
Cheers,
 -- Guido

Stanislav,

Can you please tell us what is prefered for SuSE?  We want a file location
where a user can have a file that defines 'setup' for smartmontools.  At
the moment it will just contain the command-line arguments passed to
smartd in the init script.  The choices are:
   /etc/sysconfig/smartmontools
   /etc/default/smartmontools
Which location is prefered for SuSE?

Cheers,
	Bruce

On Mon, 5 Apr 2004, Guido Guenther wrote:

> On Mon, Apr 05, 2004 at 12:22:29AM -0400, Brett Russ wrote:
> > My only issue with the below is that 99.9% of the config files in SuSE 
> > are in /etc/sysconfig.  There are ~69 conf. files there and 1 conf. file 
> > in /etc/default (on my SuSE 9.0 pro system).  Why not stick to the 
> > distro's convention since you're doing distribution specific code anyway?
> SuSE is well known for starting moves from one subdir to another with
> just some files. Are you sure /etc/sysconfig will stay the default? It
> looks to me that more and more files are moving to /etc/default, but
> this could be wrong since I didn't follow SuSE development closely
> recently.
> Cheers,
>  -- Guido
>