-
Problem report
-
Resolution: Unresolved
-
Trivial
-
6.4.20, 7.0.6
-
most modern linux kernels and zabbix agent 2
-
Sprint candidates
Steps to reproduce:
- Install zabbix_agent2 to a physical server
- Setup sudo
- Query autodiscovery like :
zabbix_get -s 12.34.56.78 -p 10050 -k smart.attribute.discovery
- Check kernel logs by dmesg -T command
Result:
[Wed Nov 27 16:49:12 2024] program smartctl is using a deprecated SCSI ioctl, please convert it to SG_IO [Wed Nov 27 16:49:12 2024] program smartctl is using a deprecated SCSI ioctl, please convert it to SG_IO [Wed Nov 27 16:49:12 2024] ata3.00: Enabling discard_zeroes_data
Expected:
no errors. Worked disk discovery
Problem description:
I noticed that the agent is trying to scan all devices executing command like this: smartctl --scan -j
It seems that the agent code iterates through different device types regardless of the result of scan.
After this, several commands are launched :
2024/11/27 17:06:15.741577 [Smart] executing smartctl command: sudo -n /usr/local/sbin/smartctl -a /dev/sda -d areca,1 -j 2024/11/27 17:06:15.741594 [Smart] executing smartctl command: sudo -n /usr/local/sbin/smartctl -a /dev/sda -d scsi -j 2024/11/27 17:06:15.741623 [Smart] executing smartctl command: sudo -n /usr/local/sbin/smartctl -a /dev/sda -d 3ware,0 -j 2024/11/27 17:06:15.741939 [Smart] executing smartctl command: sudo -n /usr/local/sbin/smartctl -a /dev/sda -d cciss,0 -j 2024/11/27 17:06:15.742138 [Smart] executing smartctl command: sudo -n /usr/local/sbin/smartctl -a /dev/sda -d sat -j
This leads to strange kernel errors like these:
program smartctl is using a deprecated SCSI ioctl, please convert it to SG_IO
Moreover, if you use the smartctl program in this way, there is no way to understand what type of queries should be used. smartctl --scan it gives me the device type "scsi", вut what we really need "sat" type.
That's why I think smartctl should be launched with a different key:
smartctl --scan-open
This is how the old template works :
https://github.com/v-zhuravlev/zbx-smartctl/blob/fae4e3bb6596abfc8c3345e4507eced46230dcbb/discovery-scripts/nix/smartctl-disks-discovery.pl#L54
I understand that the behavior of devices is quite varied and scanning can work very strangely.
Due to limited dmesg buffer people may miss some important errors. Additionally, querying devices in an unintended way may result in errors on the device.
smartctl version:
/usr/local/sbin/smartctl -V smartctl 7.4 2023-08-01 r5530 [x86_64-linux-5.4.203-1-pve] (local build) smartmontools release 7.4 dated 2023-08-01 at 10:59:45 UTC smartmontools SVN rev 5530 dated 2023-08-01 at 11:00:21 smartmontools build host: x86_64-pc-linux-gnu smartmontools build with: C++11, GCC 8.3.0 smartmontools configure arguments: '--with-update-smart-drivedb' '--with-attributelog'
kernel:
Linux vm 5.4.203-1-pve #1 SMP PVE 5.4.203-1 (Fri, 26 Aug 2022 14:43:35 +0200) x86_64 GNU/Linux
