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