Pc-sensorbewaking onder Linux
Meer veiligheid door sensorbewaking onder Linux
Je eigen computer is een optimaal afgestelde tool vol met spanningen, warmtebronnen en gevoelige onderdelen. Om hem betrouwbaar te laten werken, zijn er sensoren die in de gaten houden of de hardware het goed doet. Niet alleen onder Windows, maar ook onder Linux moet je de data van die sensoren in de gaten houden.
De hitte van de afgelopen zomer was ook voor veel pc's even zweten. Maar nu het buiten kouder is, is de verwarming weer aan en moet een pc ook bij die temperatuur zijn warmte kwijt kunnen. Als er dan een ventilator uitvalt, wordt het gevaarlijk. In het beste geval kom je daar op tijd achter omdat de cpu dan alleen nog op een slakkengangetje werkt, maar in het ergste geval worden het geheugen, de condensatoren en andere onderdelen gegrilld en wordt hun levensduur onnodig korter. Met lm_sensors (Linuxmonitoring sensors) heb je de mogelijkheid een oogje op de temperaturen, spanningen en ventilatoren te houden.
Voor Windows zijn er vaak allerlei bonte programma's van fabrikanten die het weergeven en analyseren van de sensordata op zich nemen, maar bij Linux is dat de taak van lm_sensors. Dat heeft alles wat je voor het configureren en analyseren van de sensors nodig hebt. Het zit in praktisch elke distributie en de werkwijze verschilt onderling niet wat de bediening betreft. Dit artikel geldt in principe dan ook voor alle Linuxdistributies, maar hier beschrijven we het gebruik onder Ubuntu 18.04.
Installeren
Lm_sensors is echter maar de helft van de sensorinfrastructuur onder Linux. De andere helft zijn de kerneldrivers uit het Hwmonsubsysteem, want die bekommeren zich om de communicatie met de hardware. Lm_sensors neemt het analyseren en aanpassen van de door de drivers uitgelezen waarden op zich. De kernel laadt veel van deze drivermodules niet automatisch – in tegenstelling tot de meeste andere drivers. Je moet lm_sensors een beetje helpen bij het herkennen van de ingebouwde sensoren en het laden van de bijbehorende drivers.
Om te beginnen moet je het pakket lm_sensors installeren:
sudo apt install lm_sensors
Na het installeren kun je bij wijze van test het commando sensors uitvoeren. In de meeste gevallen zie je daar een sensoruitvoer van de modules coretemp, k10temp of k8temp. Dat zijn de drivers voor de cputemperatuurdioden in Intelrespectievelijk AMDcpu's. De kernel laadt die automatisch. Dan verschijnen er afhankelijk van het processormodel en de drivers
een of meerdere temperaturen. Als je een grafische kaart van AMD of Nvidia met opensource drivers gebruikt, komen daar de grafische drivers amdgpu, radeon of nouveau bij, die naast de grafische output ook de temperaturen, ventilatortoerentallen, spanningswaarden en het stroomverbruik doorgeven.
Bovendien zitten op moederborden zogeheten SuperIOchips die verschillende waarden van de sensoren uitlezen en die doorgeven. De driver voor een SuperIOchip wordt door de kernel echter alleen geladen als je dat expliciet aangeeft. Om niet alle drivers uit te hoeven proberen, heeft lm_sensors het script sensors-detect. Met het uitvoeren van
sudo sensors-detect --auto
controleert het programma alle in aanmerking komende bussystemen en interfaces van de pc op bekende chips. Belangrijk daarbij is de parameter --auto, omdat je door de verkeerde instellingen te kiezen allerlei storingen kunt krijgen – in bijzondere gevallen kan dat zelfs tot schade aan de hardware leiden. Het automatische proces kiest altijd de absoluut ongevaarlijke opties. Die automatische modus heeft in de regel altijd de voorkeur, want anders moet je door een vervelende rondgang langs alle interfaces en instellingen, waar je bij het beantwoorden van de vragen goed op de hoogte moet zijn van de mogelijkheden van je hardware.
Aan het eind van het herkenningsproces laat het script de benodigde drivermodules in een lijst zien. Zet die modules in het bestand /etc/modules-load.d/sensors.conf. Daardoor laadt het systeem de drivers bij een volgende systeemstart automatisch. Of laad ze meteen met het commando
sudo modprobe MODULENAAM
Als het script geen sensors vindt, betekent dat niet dat er geen zijn: met name bij nieu we hardware komt het nog wel eens voor dat een fabrikant chiprevisies gebruikt die de kernel nog niet kent. Dan loont het om eens naar de hardware te kijken. Op pcmoederborden zit vaak ergens een ongeveer duimnagel grote chip die verantwoordelijk is voor de sensoren. Vaak zit je goed als je de naam Winbond of Nuvoton op de chip ziet staan. Die twee fabrikanten zijn bij de moederbordontwikkelaars erg populair. Het komt nauwelijks voor dat die naam in de handleiding staat. Dan moet je bij de kernelontwikkelaars een bugreport melden om ze op het nieuwe model te wijzen. Soms is echter ook een bepaalde moduleparameter voldoende om hem met de driver te laten werken.
Als je een notebook gebruikt, hoef je niet meteen naar de schroevendraaier te grijpen, want daar zitten vaak geen uitleesbare chips in. De warmteafvoer bij notebooks is een geheime wetenschap waar de fabrikanten niet graag wat over prijsgeven. Daarom moet je daar genoegen nemen met de temperatuursensors van de cpu.
Analyse
Als je daarna het commando sensors nog een keer uitvoert, moet je de waarden van alle gevonden meetsensors kunnen zien. Daarbij verschijnen er een aantal onwaarschijnlijke waarden. Dat komt doordat lm_sensors alle beschikbare waarden laat zien die het van de chip krijgt – ook als de betreffende input niet met een temperatuur of spanningssensor verbonden is. Vandaar dat je ergens een rare waarde als 128,0 °C kunt krijgen.
Achter de waarden staan tussen haakjes vaak nog grenswaarden, die bij overschrijden tot een alarm leiden. Of een sensor zich buiten het waardengebied bevindt, kun je zien aan een 'ALARM' aan het eind van de regel. Daarna komen soms nog meldingen, bijvoorbeeld over het type sensor dat aan het meten is.
Soms staan er onderaan de lijst waarden voor intrusiondetectionsensors. Die slaan alarm als iemand de behuizing van je pc opengemaakt heeft. Maar dat dan alleen als de behuizing een microschakelaar heeft die reageert op het openen. Dat is echter zelden het geval.
Als laatste toont sensors ook nog de status van beep_enabled. Die parameter bepaalt of een pc een akoestisch signaal moet geven als een grenswaarde overschreden wordt. Dat werkt echter niet altijd, bijvoorbeeld als er geen luidspreker aangesloten is – of die functie nog niet geïmplementeerd is.
Configureren
De getallen en de grenswaarden zijn vaak alleen door reverseengineering van de sensorchips achterhaald. Dat betekent dat ze niet op het desbetreffende moederbord toegesneden zijn, maar ze de standaarduitvoer van de chips representeren. In sommige gevallen kun je de waarden dan ook niet vertrouwen, maar moet je kijken of ze plausibel zijn en dan de sensorconfiguratie eventueel aanpassen. Alleen de drivers van de cpusensoren leveren relatief zekere waarden, want hun uitvoer wordt nauwkeurig bepaald door de specificaties van de processor.
Als je op dezelfde hardware ook Windows geïnstalleerd hebt, kun je daar mee controleren of de door lm_sensors geleverde waarden overeenkomen met het programma van de fabrikant of andere hardwaremonitoringsoftware en kijken welke benamingen de onderdelen hebben. Moderne BIOSversies hebben ook gedetailleerde weergaven en instellingen voor de sensordata. Je moet ook de grenswaarden en minimale en maximale waarden noteren. Die helpen je later bij het identificeren van de sensordata.
Bij het aanroepen van sensors lijkt het soms of de hele pc zich in een alarmtoestand bevindt. Slechts zelden zijn de grenswaarden van de sensors correct geconfigureerd en achter veel waarden staat dan ook ALARM. Voor sommige systemen staan op de GitHubprojectpagina van lm_sensors kantenklare configuraties die
de juiste waarden instellen. Soms levert even zoeken op internet ook een configuratiebestand op. Als je er een gevonden hebt, kopieer je die naar /etc/sensors.d/. Let er daarbij op dat de bestandsnaam eindigt op .conf.
Als je vanaf nul begint, kun het volgende commando uitvoeren:
sensors -u | less
De lijst die je dan te zien krijgt, laat alle sensorchips en hun inputs zien – en de bijbehorende instellingen. Daarnaast zie je ook de interne benamingen van de grenswaarden en inputnamen of labels. Voor de kernspanning van de cpu zag dat er als volgt uit:
in0: in0_input: 1.392 in0_min: 0.000 in0_max: 1.744 in0_alarm: 0.000 in0_beep: 0.000
De naam van de betreffende input is in0. Dat wordt gevolgd door in0_input: voor de huidige waarde, en daarna komen de beide minimale en maximale waarden met de suffix _min en _max die die input mag hebben. De twee laatste getallen bepalen de grenswaarden voor het alarm en het akoestische signaal. Als die op 0 staan, dan wordt dat door lm_sensors genegeerd. Afhankelijk van je systeem zie je daar meer of minder parameters staan, maar de opbouw is altijd hetzelfde.
Bij temperatuursensors komt daar nog de suffix _max_hyst bij, waarbij hyst hysterese betekent. Als de sensorwaarde bij voorbeeld de maximale temperatuur van 80 °C overschrijdt, geldt de alarmtoestand. Pas wanneer de sensor onder de lagere hysterese van 60 °C uitkomt, wordt de alarmtoestand opgeschort. Zelfs wanneer de temperatuur slechts even tot 81 °C stijgt en dan meteen weer 79 °C wordt, geldt het alarm, want er heeft zich toch ongebruikelijk veel hitte ontwikkeld. Als de waarde onder de hysterese uitkomt, dan lijkt het alsof het probleem opgelost is. Er kunnen afhankelijk van de ingebouwde chip en het sensortype nog andere parameters voorkomen. Waar die voor dienen, kun je het beste eens bekijken bij de documentatie van Hwmon van de Linuxkernel. Die documentatie en andere extra informatie kun je vinden via de link op de volgende pagina onderaan dit artikel.
Open vervolgens in de directory /etc/ sensors.d/mijn-sensors.conf om een aangepaste configuratie voor je hardware te maken. Op de volgende pagina staat een voorbeeld.
Het configuratiebestand begint met het sleutelwoord chip, gevolgd door de typenaam van de chip. Daarna volgt een suffix, die het bussysteem voor de chip vastlegt. Daar gebruik je de placeholder -* voor, want bij de gebruikelijke pchardware bestaat er maar één chip van dat type in het systeem.
De inputbenaming stel je in met het sleutelwoord label, gevolgd door de interne benaming van de input en de tekst die je als naam wilt gebruiken:
label in7 "System +3V"
Hier wordt van in7 de input 'System +3V' gemaakt. Om grenswaarden als in7_max in
te stellen, gebruik je het sleutelwoord set van je configuratie:
set in7_max 3.63 set in7_max 3.3 * 1.1
Beide regels doen hetzelfde, want je kunt de waarden absoluut aangeven of rekenkundige operatoren gebruiken. Beide setcommando's stellen de waarde 3,63 volt (3,3 volt nominaal plus 10 procent tolerantie) als maximale waarde voor de sensor in. De tweede variant is echter beter leesbaar en makkelijker te corrigeren als je de tolerantie kleiner wilt maken of vergroten. Als je bij de sensors waarvoor geen minimale en maximale waarden ingesteld zijn die waarden toch instelt, moet ook de alarmmelding daarachter verdwijnen.
Vaak zijn er sensorwaarden die te hoog of te laag zijn, Bij spanningen komt dat door het kleine meetbereik van de chips. Dat loop meestal van 0 tot 3,3 of 5 volt. Daardoor kan die chip hogere spanningen alleen indirect meten. Je moet de uitvoer daarvan aanpassen, zodat de waarde 1,008 V overeenkomt met de eigenlijk gemeten 12,096 V. Het achterhalen van de werkelijke waarde moet je zelf voor elkaar zien te krijgen. Daar kun je de onder Windows genoteerde waarden voor gebruiken en dan kijken welke van de data van lm_sensors zodanig om te rekenen zijn dat ze de gezochte meetwaarden representeren. Dan moet je even afwachten of de meetwaardeschommelingen, als die er zijn, zich binnen de verwachte orde van grootte bevinden. Vervolgens moet je dan nog berekenen of andere sensoren wellicht voor de gezochte meetwaarde in aanmerking zouden kunnen komen. Welke er het beste voor in aanmerking komt, moet je zelf beslissen. Afhankelijk van de sensor heb je nog meetwaarden over, die niet toe te wijzen zijn. Je kunt die dan gewoon weglaten of negeren.
Als je de sensorwaarde ontdekt hebt die je moet corrigeren, dan kun je compute gebruiken om rekenoperaties op de meetwaarde los te laten:
compute temp1 @/2 , @*2 set temp1_max 40
Daar moet je wel even goed bij opletten, want daarmee wordt niet alleen de inputwaarde van een sensor omgerekend, maar ook alle met die input samenhangende waarden. Daarom staat hier ook alleen maar temp1 en niet temp1_input achter het sleutelwoord. De grenswaarden worden net zo omgerekend als de inputdata.
De parameters van compute hebben de volgende volgorde: eerst komt de te corrigeren input (temp1), vervolgens twee door een komma gescheiden operaties. De eerste operatie geeft aan hoe lm_sensors de door de driver geleverde meetwaarden moet aanpassen voordat ze weergegeven worden. Als de driver bijvoorbeeld een waarde van 72 °C levert, maar je weet dat de werkelijk temperatuur maar half zo hoog is, dan deel je die door twee. De @ is de variabele voor de door de driver geleverde waarde. Door het delen komt de uitvoer van lm_sensors overeen met de werkelijke waarden van 36 °C.
De operatie achter de komma werkt precies andersom. Daar wordt gedefinieerd hoe lm_sensors waarden moet berekenen die de gebruiker heeft ingesteld, voordat ze aan de driver worden doorgegeven. De door set ingestelde maximale waarde voor deze sensor is bijvoorbeeld 40. Dan wordt die waarde door lm_sensors vermenigvuldigd met twee. Het resultaat (80) wordt doorgegeven aan de driver, zodat die een maximale waarde doorkrijgt die aangepast is aan de te hoge temperatuurwaarden.
Bij sommige sensors volstaat het om de eerste parameter te corrigeren en de tweede op de oorspronkelijke waarde (@) te laten staan. Of dat zo is, moet je uit proberen. Bij het omrekenen kun je alle vier de basisoperaties gebruiken, met haakjes werken of een minteken voor een waarde zetten om hem om te keren.
Als je je configuratie klaar hebt, voer je een keer het commando sudo sensors -s uit. Het programma leest de configuratie dan opnieuw in en past de sensorinstellingen aan door waarden in het door de driver in /sys beschikbaar gestelde bestand te schrijven. Een nieuwe aanroep van sensors moet dan de veranderingen weerspiegelen. Als er fouten in het configuratiebestand staan, dan meldt het programma dat en laat het de regels zien waar de problemen zitten.
Als je inputs wilt verbergen die onzinnige dingen laten zien, dan kun je dat in het configuratiebestand doen met het sleutelwoord ignore.
Weergeven en loggen
Om de meetwaarden weer te geven zijn er verschillende programma's. Psensor is bijvoorbeeld een programma met felgekleurde grafieken, ondersteuning voor schijftemperaturen, het geheugenverbruik en ook de processorbelasting. Voor een desktopomgeving zijn er allerhande applets en uitbreidingen die je de sensordata kunnen laten zien.
Bij Gnome 3 is Freon daar een goed alternatief voor en voor Xfce is er de Sensorsplugin. Conky en Gkrellm, de aloude klassiekers onder de systeemmonitoren, laten de sensordata bijzonder fraai zien.
Als je de sensordata wilt loggen, kon je vroeger sensord gebruiken, dat bij lm_sensors hoort, maar helaas zit die daemon niet meer in de pakketbronnen van Ubuntu. De functionaliteit daarvan was sowieso al erg beperkt, zodat je beter een monitoroplossing als Nagios of Check_MK [1] kunt gebruiken.
Als je zelf iets voor het verwerken van de sensordata wilt programmeren, moet je rechtstreeks uitlezen uit /sys vermijden en in plaats daarvan de libsensorsAPI gebruiken. Alleen op die manier krijg je alle correcties die voor de aanwezige sensors toegepast worden meegeleverd en hoef je je niet zelf bezig te houden met het omrekenen van de waarden. (nkr)
Literatuur
[1] Peter Siering, Controleren is beter, Netwerk- en serverdiensten monitoren met Check_MK, ct 7-8/2018, p.136