smartd doesn't notice newly added devices afters start

[calestyo]

Forwarded from: ​https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=893665

Hi.

It seems that smartd, even with a configuration like:
DEVICESCAN -d auto -d removable …
(i.e. similar or equal to the default config in Debian), doesn't
detect devices which are added after (i.e. removable
devices) the daemon was started.

Example:
1) Start smartd (respectively it runs from system boot)

It "sees" my internal SSD.

2) I add an external HDD via USB-SATA-bridge.

The USB-SATA-bridge I'm using requires no special smartmontools
config, i.e. smartctl --all /dev/sdX works out of the box.

Now even if I wait for the default of 1800s (after which it would
"check" again) it doesn't *not* take note of the new device and
add it to the monitored ones.

Only if I SIGHUP the daemon, it will actually see and add it.

So the first problem here is that smartd never seems to scan
for new devices on it's own.

Even if it would, that would IMO not really solve the problem, as
a maximum of 30 min (assuming the default interval) is probably too
long to take note of SMART issues.
Mostly because it can easily happen that an external device isn't
even connected for so long (e.g. I just connect it to get some data
on it and then I remove it again).

I also think, that sending SIGHUP automatically (e.g. via some cron job
or systemd timer) is not really the best solution, as it would also cause
the config to be read in again (which may be just edited).

The best thing would probably be if udev or systemd could somehow
magically inform smartd when a new device is added (ideally without
the later reading in the configs again).
Then, smartd could immediately make a first check, thus the device would
get checked even if it was removed again before the 30 mins.

One word of caution though:
IMO it would be bad, if any cron/systemd/udev solution would actually
start smartd.
If one does e.g. digital forensics and intentionally stops smartd.serice
in order to prevent any SMART commands being run on devices... it shouldn't
come back by itself ;-)

Thanks,
Chris.

[calestyo]

And a further problem:

Once smartd monitors a removable device... it spits out errors (that it
cannot open it) just because the device was removed.

This would also be solved by some proper add/remove handling of
removable devices.

Cheers,
Chris.

[Christian Franke]

And a further problem:

Once smartd monitors a removable device... it spits out errors (that it
cannot open it) just because the device was removed.

This is already fixed since r4399. If problem persists after upgrading to smartmontools 6.6, create a new ticket.

[Christian Franke]

It seems that smartd, even with a configuration like:
DEVICESCAN -d auto -d removable …
(i.e. similar or equal to the default config in Debian), doesn't
detect devices which are added after (i.e. removable
devices) the daemon was started.

Yes, detecting hot plugged devices is still an open issue.

I also think, that sending SIGHUP automatically (e.g. via some cron job
or systemd timer) is not really the best solution, as it would also cause
the config to be read in again (which may be just edited).

I don't see major drawbacks if smartd.conf is reread after new devices have been detected.

The best thing would probably be if udev or systemd could somehow
magically inform smartd when a new device is added (ideally without
the later reading in the configs again).

A very first experimental solution could be an external tool which detects hotplug events and sends a SIGHUP to smartd after some short delay.

A general solution is complex because hotplug detection is platform specific.

Patches are welcome.

[Christian Franke]

Ticket #1016 has been marked as a duplicate of this ticket.

[Christian Franke]

See ticket #60.