Tutto è partito per cercare di far funzionare bene Stadia su Linux, che sul mio sistema linux + nvidia a 1080p lagga da far paura, anche quando la connessione internet è buona.
Da questo è partita una attività di ottimizzazione di chromium per gestire al meglio l'accelerazione hardware su NVIDIA e la riproduzione di video che voglio documentare, a prescindere da Stadia (che, comunque, continua ad andare male).
Se munin ha registrato un dato anomalo potrebbe sballare tutti i grafici, rendendoli illeggibili.
La soluzione è spiegata in questa guida ufficiale: http://guide.munin-monitoring.org/en/latest/howtos/remove-spikes.html
Il problema è che quella guida tiene conto solo dei picchi POSITIVI: se il vostro problema è in un picco negativo non lo risolverà. Ad esempio nel caso di un plugin che usa la direttiva "negative" per inserire dei dati come valori negativi del grafico (caso classico dei rilevatori di velocità di rete upload/download).
Sto testando alcuni sensori di temperatura zigbee a basso prezzo (tutti attorno ai 10€, poco più o poco meno). I sensori zigbee sono comodi perchè sono piccoli, vanno a batteria e quindi, non avendo connessione alla rete elettrica, possono essere messi un po' ovunque in maniera molto flessibile. Il loro problema principale è che, per consumare poco, non comunicano costantemente i loro dati, ma solo a intervalli. In genere hanno un intervallo di tempo prestabilito per comunicare la lettura. Questo intervallo di tempo può diminuire se si verifica una variazione oltre una certa soglia del valore letto.
Questo aspetto li rende poco adatti per un sistema "a termostato", che permette di regolare l'accensione di una caldaia. O per lo meno il sistema diventa molto impreciso: per un termostato è importante riuscire a leggere tempestivamente variazioni anche di 0.1°, altrimenti si rischia di accendere la caldaia troppo tardi (quando la temperatura ha già iniziato a scendere troppo rispetto al setpoint), o di spegnerla troppo tardi (con aumento dei consumi).
In ogni caso sensori diversi si comportano diversamente, e quindi ne ho messi alla prova 3:
Il problema che sto per descrivere l'ho avuto con una stampante HP (e quindi installandola con HPLIP), ma è probabilmente comune anche ad altre stampanti.
Scenario: installo la stampante su una macchina server, la imposto come condivisa, poi su una macchina client, usando l'interfaccia di cups (ma anche quella di HP), installo la stampante remota.
Problema: tutte le stampe che faccio dal client vanno in errore per "Filter failed".
I miei pc sono configurati per avere uno swap minimo dal momento che in genere la memoria ram basta e avanza, ma ogni tanto capita, a causa di sviste o bug, che la memoria si riempie completamente e il sistema diventa inutilizzabile.
Basterebbe riuscire a fare un kill, anche solo poter entrare in un terminale testuale per farlo, ma spesso è impossibile. In teoria il kernel dovrebbe avere un "OOM killer" (out of memory killer) che si occupa di eliminare un processo per rendere il sistema nuovamente reattivo, ma in pratica non viene eseguito mai.
Recentemente ho trovato una soluzione che sembra molto promettente e sto testando su tutte le mie macchine desktop:
