smartd fails to start after upgrade from F14 to F15

[Mark Eggers]

smartd fails to start on boot after I upgraded from Fedora 14 to Fedora 
15.

Right now I'm using the default /etc/smartd.conf file (which is not 
ideal). This uses the default scanning values, which are:

DEVICESCAN -H -m root -M exec /usr/lib/smartd_actions -n standby,10,q

/usr/lib/smartd_actions does not exist, so obviously if there is a 
problem I won't get notified about it.

A more reasonable set of lines for my system would be:

/dev/sda -H -l selftest -l error -f
/dev/sdb -H -l selftest -l error -f

However, even with the sub-optimal configuration, issuing the following 
command as root starts smartd.

systemctl start smartd.service

The two disks are found as indicated by messages in /var/log/messages.

Jun  7 13:40:20 phoenix smartd[9511]: Monitoring 2 ATA and 0 SCSI devices
Jun  7 18:48:59 phoenix smartd[4813]: smartd 5.40 2010-10-16 r3189 [i386-
redhat-linux-gnu] (local build)#012Copyright (C) 2002-10 by Bruce Allen, 
http://smartmontools.sourceforge.net#012
Jun  7 18:48:59 phoenix smartd[4813]: Opened configuration file /etc/
smartd.conf
Jun  7 18:48:59 phoenix smartd[4813]: Configuration file /etc/smartd.conf 
was parsed, found DEVICESCAN, scanning devices
Jun  7 18:48:59 phoenix smartd[4813]: Device: /dev/sda, type changed from 
'scsi' to 'sat'
Jun  7 18:48:59 phoenix smartd[4813]: Device: /dev/sda [SAT], opened
Jun  7 18:48:59 phoenix smartd[4813]: Device: /dev/sda [SAT], found in 
smartd database.
Jun  7 18:48:59 phoenix smartd[4813]: Device: /dev/sda [SAT], is SMART 
capable. Adding to "monitor" list.
Jun  7 18:48:59 phoenix smartd[4813]: Device: /dev/sdb, type changed from 
'scsi' to 'sat'
Jun  7 18:48:59 phoenix smartd[4813]: Device: /dev/sdb [SAT], opened
Jun  7 18:48:59 phoenix smartd[4813]: Device: /dev/sdb [SAT], found in 
smartd database.
Jun  7 18:48:59 phoenix smartd[4813]: Device: /dev/sdb [SAT], is SMART 
capable. Adding to "monitor" list.
Jun  7 18:48:59 phoenix smartd[4813]: Monitoring 2 ATA and 0 SCSI devices
> From what I can tell, /lib/systemd/system/smartd.service looks reasonable.

[Unit]
Description=Self Monitoring and Reporting Technology (SMART) Daemon
After=syslog.target

[Service]
EnvironmentFile=/etc/sysconfig/smartmontools
ExecStart=/usr/sbin/smartd -n $smartd_opts

[Install]
WantedBy=multi-user.target

Any thoughts would be greatly appreciated.

Thanks in advance . . . .

/mde/

[Sam Varshavchik]

Mark Eggers writes:
> smartd fails to start on boot after I upgraded from Fedora 14 to Fedora
> 15.
>
> Right now I'm using the default /etc/smartd.conf file (which is not
> ideal). This uses the default scanning values, which are:
>
> DEVICESCAN -H -m root -M exec /usr/lib/smartd_actions -n standby,10,q
>
> /usr/lib/smartd_actions does not exist, so obviously if there is a
> problem I won't get notified about it.
>
> A more reasonable set of lines for my system would be:
>
> /dev/sda -H -l selftest -l error -f
> /dev/sdb -H -l selftest -l error -f
>
> However, even with the sub-optimal configuration, issuing the following
> command as root starts smartd.
>
> systemctl start smartd.service

If so, then "systemctl enable smartd.service" will fix this.

There are a number of packages whose %post scriptlet is broken and enables  
their systemd units only when installing the package for the first time.  
When upgrading from F14 to F15, of course, this does not happen, so their  
systemd unit never gets enabled.

You probably also have rsyslog.service fail to come up for the same reason,  
and it should be enabled. I also had dhcp and inn require a manual enable;  
there are probably others, too.

[Mark Eggers]

On Wed, 08 Jun 2011 06:56:41 -0400, Sam Varshavchik wrote:

-- snip --
> If so, then "systemctl enable smartd.service" will fix this.

This appears to have created the non-existent link:

/etc/systemd/system/multi-user.target.wants/smartd.service
> There are a number of packages whose %post scriptlet is broken and
> enables their systemd units only when installing the package for the
> first time. When upgrading from F14 to F15, of course, this does not
> happen, so their systemd unit never gets enabled.
>
> You probably also have rsyslog.service fail to come up for the same
> reason, and it should be enabled. I also had dhcp and inn require a
> manual enable; there are probably others, too.

rsyslog.service seems to be running for me by default and doesn't show in:

systemctl --all | grep error

Oddly enough abrtd does show in the list above, even though there is a 
link in /etc/systemd/system/multi-user.target.wants/ and it shows running 
via:

ps -aef | grep abrtd | grep -v grep

I think quality time with the systemd documentation is required.

Thanks for the hint, I'll look at the other "wants" directories to make 
sure they make sense.

. . . . just my two cents.

/mde/