Custom Query (1451 matches)

Hi,

could you please add the drive for the MARVELL Raid VD to the database?

The Marvell BIOS Utility is included into the HPE ProLiant MicroServer Gen10.

Many thanks!

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

(Issue (1) described bellow may not apply to upstream smartmontools, as /etc/smartmontools/run.d/10mail seems to be a Debian-specific file... but at least issue (2) should apply to upstream smartmontools as well.)

Hi.

I've stumbled over the following issues in smartd:

At first I had bascally the following smartd.conf:

DEVICESCAN -d auto -d removable -n standby,4 -a -m root,mylocaluser,my@email.com -M exec /usr/share/smartmontools/smartd-runner

In order to test it, I've added -M test.

Now on restart, only root got mail, and the postfix logs didn't even show any tries for mylocaluser and my@….

I've added -M once, as I assumed the support for comma-separated multiple addresses as explained in the smartd.conf manpage for -m, may just not work with -M-exec-invoked /etc/smartmontools/run.d/10mail but only with -M once, -M daily or -M diminishing (and that this might be some other mail sender than /etc/smartmontools/run.d/10mail - which it actually seems to be).

Interestingly, it still didn't work. Only if I removed -M exec... I got mail sent to all three recipients.

So I think there are two issues here: 1) /etc/smartmontools/run.d/10mail, which seems to be used per default by debian (as there is no -M once or so) should support multiple addresses in -m. It's likely not obvious to the user that there are two methods of sending warning mails, and it should just work as one would naively assume by reading the documentation of -m.

2) In contrast to what the manpage claims, it seems that if -M exec is in place, -M once/etc. are not executed as well.

IMO both are severity=important, as they may prevent information about failing drives being passed on.

Cheers, Chris.

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.