Hi, On 2022-07-22 07:18, Roman Mamedov wrote: > Package: hddtemp > Severity: wishlist > > Hello, > > I have been surprised to see the changelog entry about the planned removal of > hddtemp. I would like to leave a couple of comments to that. > > > hddtemp has been dead upstream for many years and is therefore in a minimal > > maintenance mode. It will be shipped in the Debian Bullseye release, but > > will not be present in the Debian Bookworm release. > > Could it be a case of a program that is basically _done_, i.e. it works, keeps > working, and doesn't need any changes or new features, other than "minimal > maintenance" in the first place?
Definitely not. Maintenance has been done in Debian for many time, with 54 debian specific uploads for the current beta version released upstream 16 years ago. In addition this program will never be _done_, as by design there is a need to maintain a database of drives, contrary to the kernel module. And it doesn't support NVME or SAS drives that will eventually replace SCSI or SATA drives. > Or could you give some examples of issues that arise and go unsolved because > of "dead" upstream? Seeing from next to no bugreports in Debian, doesn't seem > that there are many. All the bugs have been closed when the package has been removed. Please find the list below. https://bugs.debian.org/235427 https://bugs.debian.org/316552 https://bugs.debian.org/331446 https://bugs.debian.org/479840 https://bugs.debian.org/654875 https://bugs.debian.org/668961 https://bugs.debian.org/727820 https://bugs.debian.org/740732 https://bugs.debian.org/758748 https://bugs.debian.org/833147 https://bugs.debian.org/854484 https://bugs.debian.org/854806 https://bugs.debian.org/891501 https://bugs.debian.org/924950 https://bugs.debian.org/961817 https://bugs.debian.org/981462 Please note that bug #740732 even asked hddtemp to be removed as the package was bit rotting. I also regularly receive "my hard drive is not recognized" bugs through private mails. In addition hddtemp needs to run as root as a SUID binary. While it was something usual 20 years ago when the architecture of the hddtemp has been designed, this is not the case anymore. Given the state of the software, it's likely a good candidate for privilege elevation. > > Nowadays the 'drivetemp' kernel module is a better alternative. It uses the > > Linux Hardware Monitoring kernel API (hwmon), so the temperature is > > returned > > the same way and using the same tools as other sensors. > > Does not seem to be the case. Of course running "sensors" then returns: > > > drivetemp-scsi-4-0 > > Adapter: SCSI adapter > > temp1: +32.0°C (low = +0.0°C, high = +60.0°C) > > (crit low = -40.0°C, crit = +65.0°C) > > (lowest = +28.0°C, highest = +42.0°C) > > And what I wanted to know was the temperature of /dev/sda. > > There is no "sensors /dev/sda" obviously, and not obvious for the user how to > easily convert sda to scsi-X-Y. Calling *this* the better alternative seems > extremely premature. Indeed that is not perfect, however it has the advantage to have a stable name that depends on the connection and not the way the devices are discovered. You can lookup the relation by looking at the /sys/block/sd*/device link. However it is way more integrated to existing temperature monitoring software, as it uses the hwmon interface, and reports the temperature the same way as NVME drives. > At least some wrapper should be introduced (or maybe there's already one?) > that would offer the exact command-line interface as hddtemp, but then > retrieve the temperature in "the better way" under the hood (if there's really > such a pressing need...) A wrapper would indeed be a good idea. That said the non-existence of such a wrapper is not a reason to keep hddtemp any longer. And it doesn't replace the daemon mode of hddtemp. Anyway do not hesitate to contribute such a wrapper. > Not to mention it would return 24 of these paragraphs when called > (interrupting all the drives to fetch temperature?), assuming e.g. 24 drives, > even if I wanted the temperature of just one. That's just bad faith. Just looking at the sensors manpage would have shown you that you can path the name of the drive (in your case "drivetemp-scsi-4-0") as an argument. And while it indeed takes a tiny piece of bandwidth to fetch the temperature, contrary to the kernel driver the temperature is cached for sometime to avoid interrupting the drive too often. And contrary to hddtemp, the driver avoids waking-up the drive. > > Loading this module is as easy as creating a file in the > > /etc/modules-load.d > > directory: > > > > echo drivetemp > /etc/modules-load.d/drivetemp.conf > > Loading it might be easy, but as one proverb says, "only if you're not > interested in the results"... The replacement is definitely not perfect and users need to adapt a bit their usage or their scripts. On the other hand it has a lot of benefits in terms of security, reliability and maintainability. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
