Linux

Is there any progress on this?

This isn't really a minor - for any machine that has a lot of drives, the drives will rename after a reboot and if a drive has issues, it'll make a problem. Now, after a reboot, I get this "SMART [sdb sat]: Disk has been replaced (new serial number received)", which is normal, since sdb isn't a fixed drive and the drive most definetely hasn't got a new serial number, but just another name. Could you look into this, please? I've shown how I did it - it's not hard.

Are you working on this? It's not like it's hard work to fix it!

it's taken more than a year now and the fix should be rather easy. What's stopping you?

Good day! We are currently fixing other related SMART issues and the stability of the SMART plugin, we will try to get to this issue after those have been fixed.

Would you have any suggestions how to reproduce this issue constantly on a smaller device count? As finding DEV devices with 20-80 drives is quite troublesome.

esneiders that sounds great!
suggestion: you need to know the root cause: it happens because harddisks  have different response times to say "yes I'm here" .. so the easiest thing would be to just plugin other harddisks one second later

RoyK if you think is that easy, zabbix is opensource - so  why don't you create a pull request?

esneiders The root cause is described here https://wiki.archlinux.org/title/Persistent_block_device_naming

shad0w I have described above how I did this in perl, just to show it that way. However, I'm not fluent in Go, so I don't really want to start hacking, resulting in something so ugly I'll get banned for it anyway.

Here's a simpler way, in bash

$ find -L /dev/disk/ -samefile /dev/sda -exec ls -l {} \;
lrwxrwxrwx 1 root root 9 Jun 10 13:09 /dev/disk/by-diskseq/1 -> ../../sda
lrwxrwxrwx 1 root root 9 Jun 10 13:09 /dev/disk/by-path/pci-0000:06:00.0-sas-phy3-lun-0 -> ../../sda
lrwxrwxrwx 1 root root 9 Jun 10 13:09 /dev/disk/by-id/wwn-0x5000c500e53d3ede -> ../../sda
lrwxrwxrwx 1 root root 9 Jun 10 13:09 /dev/disk/by-id/ata-ST16000NM001G-2KK103_ZL2PS47V -> ../../sda

esneiders the problem shouldn't be hard to reproduce. Happens e.g. all the time on my desktop when I reboot it. After a restart the naming of the devices changed. Or I stumbled into that bug, because we use an Intel NUC as a VPN gateway. It has a eMMC and for reasons I have /var/log on an sd card. And there after nearly every reboot /dev/mmcblk0 and /dev/mmcblk1 are swapped.

And this doesn't only affect smart monitoring. I noticed it because of the eMMC and sd card I had to adjust $VFS.DEV.READ.AWAIT.WARN and $VFS.DEV.READ.WRITE.WARN which obviously fails when the drives swapped their names.

shad0w findsamefiles.go I beleive this should show a way to do it.

$ go run findsamefiles.go sda
/dev/sda -> [/dev/disk/by-id/ata-ST16000NM001G-2KK103_ZL2PS47V /dev/disk/by-id/wwn-0x5000c500e53d3ede]

Apologies for not posting a pull request. I don't speak go that well, so I guess other people in here can integrate this in a better way than I.

Creds to ikke @irc for the code - I just modified it slightly to return an array of hits instead of a single one

This bug was originally flagged as trivial by Zabbix, but AFAICS, it yet haven't been touched. Can someone at Zabbix please update me?

esneiders any news about this?

maybe a solution could be the type which smartctl --scan is looking for:

smartctl --scan -d by-id

this is not documented: https://github.com/smartmontools/smartmontools/issues/295

and it would be great, if this get a higher prio, because it's very annoying to get spammed every time a storage-server gets rebootet

It might be easier to just modify the discovery script and template to use disk serial number as the unique identifier (since that's more or less that the disk id is anyway). Should only require smart.disk.get[] to be updated to support retrieving data by disk serial, and the rest is in the template.