Get Smart! (SMART Usage Attribute: 194 Temperature_Celsius changed from X to Y)

Da quando ho attivato il supporto SMART per il monitoraggio degli hard disk, mi trovo sempre un misterioso messaggio sui log di sistema:

/dev/sdb : Usage: Temperature_Celsius (194) changed to 157, 162, 157, 162

Considerato che non vedo ne' fiamme ne' fumo provenire dal CED, mi pare impossibile che i dischi stiano viaggiando su temperature (in gradi celsius) cosi' alte.
Vediamo la situazione attuale con con il comando:

smartctl -a /dev/sdb

Viene visualizzato questo Output (mostro solo la parte interessante per questo post):

ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
(...)
194 Temperature_Celsius 0x0002 162 162 000 Old_age Always - 37 (Lifetime Min/Max 25/42)
(...)

37 mi sembra una temperatura piu' credibile (anche toccando fisicamente il disco non mi si e' liquefatta la mano).
Il problema e' causato dal una errata configurazione di smartd, il demone che si occupa di monitorare i dischi.
Questo infatti registra sui log non la temperatura reale (registrata nella colonna RAW_VALUE) bensi' il valore delle colonne VALUE e WORST.
Per convincere smartd a usare correttamente i dati sulla temperatura bisogna utilizzare il parametro

-R 194

ad esempio sul mio sistema ho modificato nel file /etc/smartd.conf la riga:

DEVICESCAN -m root -M exec /usr/share/smartmontools/smartd-runner

in

DEVICESCAN -m root -R 194 -M exec /usr/share/smartmontools/smartd-runner

Possiamo modificare ulteriormente questa riga in modo da segnalare le variazioni (ad esempio) maggiori o uguali a 4 gradi celsius:

DEVICESCAN -m root -R 194 -W 4 -M exec /usr/share/smartmontools/smartd-runner

Una ulteriore modifica per segnalare il raggiungimento di un limite (seppur considerato ancora in sicurezza) in questo caso 45 gradi celsius:

DEVICESCAN -m root -R 194 -W 4,45 -M exec /usr/share/smartmontools/smartd-runner

Una ulteriore modifica per segnalare il raggiungimento di un limite critico, in questo caso 55 gradi celsius:

DEVICESCAN -m root -R 194 -W 4,45,55 -M exec /usr/share/smartmontools/smartd-runner

Il parametro

-m

(presente in tutti gli esempi) indica a smartd di inviare una mail all'utente indicato (o a piu' utenti separati da virgole) in caso di errore grave (o di raggiungimento di limite critico).

mt-daapd non parte piu'!!!!

Si si , non vi fidate di chi dice che avahi non serve sui server :)
Dopo averlo rimosso (vedi post precedente) mt-daapd ha smesso di funzionare.
Si rifiutava di partire senza il suo compagno di giochi avahi.
Per tranquillizzarlo e' necessario farlo partire con l'opzione

-m

Aprite il file /etc/init.d/mt-daapd
trovate la linea (a inizio file)

DAEMON=/usr/sbin/mt-daapd

subito dopo, se non esiste, aggiungete la linea

DAEMON_OPTS=-m

oppure aggiungete il

-m

alla esistente linea

DAEMON_OPTS=

Ora potete rieseguire mt-daapd con il comando

/etc/init.d/mt-daapd start

Avahi? No grazie, preferisco un rabarbaro

Credo di aver capito la ragione di certi strani comportamenti che avevano afflitto il networking di certi server debian utilizzati per l'ultimo corso. La colpa potrebbe, accetto eventuali smentite, essere di avahi che su un server pare sia di troppo (ma 'ndo avahi?).

Per star tranquillo ho provato a disabilitarlo sul mio server (mi impediva ad esempio di eseguire rsnapshot su server remoti tramite ssh):

/etc/init.d/avahi-daemon stop
sudo update-rc.d -f avahi-daemon remove

se volete riattivarlo al boot successivo lanciate il comando:

sudo update-rc.d -f avahi-daemon defaults

Shift, CTRL, ALT e Caps Lock in sciopero???

Notte di rilasci, vuoi che non saltasse fuori qualche avvenimento folkloristico-informatico?
Ebbene i 4 tasti citati nel titolo hanno smesso di funzionare all'improvviso...per ben 3 volte.

Il problema e' quasi sicuramente legato a VMware, forse ai VMware Tools, e' stato riscontrato sia con server che workstation.

Nel mio caso stavo utilizzando la VMware Remote Console di un Ubuntu 9.04 collegata a un VMware server 2.0 installato su una Debian Lenny a 64bit.

Se ne parla nel bug 195982

SOLUZIONE 1

aprire un terminale e lanciare il comando:

setxkbmap

SOLUZIONE 2

eseguire un logoff
rientrare

Qualcuno ha trovato che in corrispondenza di questo problema era sparita l'indicazione di DEFAULT nei layout di tastiera in System->Settings->Keyboard and select layout

GNOME: icone cestino e dischi montati

Sia che le vogliate visualizzare o che le vogliate nascondere la procedura e' la stessa.
Lanciate il comando:

gconf-editor

Andate almenu:

/apps/nautilus/desktop

Le voci da modificare sono

volumes_visible

per visualizzare o meno l'icona dei dischi montati e

trash_icon_visible

per il cestino.

Esecuzione automatica di script contenenti comandi zenity

Avete uno script che utilizza zenity ma se lo inserite nei programmi avviati da Gnome in automatico non riesce a visualizzare nulla?
Utilizzate questa sintassi come linea di comando:

sudo -s -u $USER NOME_DELLO_SCRIPT

Premuratevi anche di lanciare il comando:

visudo

e di aggiungere questa linea:

username ALL=(ALL) NOPASSWD:NOME_DELLO_SCRIPT

Completiamo il tutto inserendo nelle prime linee dello script:

xhost local:$USER

SW installato: Hard Disk Sentinel Linux Edition

hdsentinel e' un bel programmino (free nella sua versione Linux) per il monitoraggio dei vostri hard disk.
Lo potete trovare sul sito http://www.hdsentinel.com/hdslin.php