Ricerca tra la vecchia roba

Vuoi liberare spazio ma non si libera

Posted: maggio 20th, 2010 | Author: | Filed under: crash, Life, linux | Commenti disabilitati su Vuoi liberare spazio ma non si libera

Nelle puntate precedenti avevo usato logrotate per liberare del fucking space siccome mi si era riempito il filesystem radice; è successo di nuovo, però nella mia fucking debian dove purtroppo il disco era talmente pieno che logrotate non funzionava (sempre i file di log si riempiono di fottuta merda); preso dallo sconforto e della cattiveria intrinseca dei computer che fanno di tutto per evitare che io non bestemmi, ho dato un bel rm sui file… il problema a questo punto è che in realtà il prode df mi dava sempre 100% di usage, di fucking usage… cancella qualcos’altro, sempre 100%… dio porcooooo

Poi allora uno cerca, fucking google, cose come "linux doesnt’ free space df" (scritto sbagliato perché fa figo) e cosa ottengo, questo:

After some research it turned out that files currently open and are
deleted will not release the free space until the process using it was
stopped.

Ma vaffanculo, usando

 # /etc/init.d/sysklogd restart

la mia giornata (forse) ritorna a brillare…

 

awesome dancing

 


Come liberare spazio quando /var/log/messages cresce a dismisura

Posted: marzo 10th, 2010 | Author: | Filed under: crash, linux | 2 Comments »

Nei sistemi *nix tutte (o quasi) le operazioni di sistema vengono loggate in appositi files in /var/log/ e può succedere che per problemi a qualche applicazione, quest’ultima riempia qualche file di log del sistema con messaggi che essendo di testo e ripetuti insistentemente, possono portare ad esaurimento del disco. Nel mio caso ho visto che risultava un problema di Full Device ed ho cercato di pulire il disco eliminando eventuali vecchi pacchetti tramite

# eclean distfiles

nella mia gentoo; per chi avesse la fucking Debian può usare

# apt-get clean

Tuttavia il problema persisteva e quindi ho usato la magia della shell per scovare i file con dimensione superiore a 500MB

# find / -size +500M -print0 | xargs –null ls -Ssh | less

e a quel punto è parso evidente quale fosse il problema

# ls -sh /var/log/messages
1,3GB /var/log/messages

Praticamente il sistema pulseaudio (che non mi ha mai funzionato) ha riempito quel file di merda e quindi mi tocca pulirlo; la prima idea sarebbe stata quella di cancellarlo al volo, ma siccome è una soluzione priva di stile, ho pensato che deve esistere un comando adeguato a eseguire la cosiddetta "rotazione" dei file di log ed infatti esiste: logorotate(1).

Eseguendo questo magico comando

# logrotate -f /etc/logrotate.conf

si obbliga il nostro sistema di comprimere e salvare a fianco ai vecchi log quel macigno  che ostruiva il filesystem. I computer sono il male.


Quando i kernel fanno Ops

Posted: marzo 15th, 2009 | Author: | Filed under: crash, linux | Commenti disabilitati su Quando i kernel fanno Ops

Succede che stamattina voglio inserire una scheda sonora sullo pseudo-server che ho a casa in modo da poter grabbare l’audio dala scheda TV entrata in mio possesso da un vecchio computer di un mio amico. Succede che la monto e avvio il sistema. Succede che ad un certo punto mi esce un Ops del kernel all’inserimento del modulo e il tutto è bloccato.

Potrei semplicemente togliere la scheda, ma si sa, le sfide ci sfidano e quindi voglio vedere se è proprio il modulo oppure chi lo sa? la digos che cerca di penetrare la mia rete casalinga attraverso il firmware della scheda (devo bere di meno alle cene benefit)…

Primo fatto è che devo conoscere quale modulo è stato in particolare… già di suo il kernel presenta un backtrace del processo che ha fatto il bordello, ma magari vogliamo sapere di più e così usiano la comoda procedura Ctrl-Alt-PrintScreen-<alzare un elefante> che peraltro ci serve anche per riavviare senza usare il tasto reset che fa tanto ficoooo.

Il problema successivo ovviamente è che il sistema si blocca anche in modalità single (voglio la modalità erotomane) e quindi bisogna agire sui parametri dl kernel al boot per evitare che esegua la procedura di init(1) ma che ci lasci con una bella shell.

Quando arriva Grub non bisogna fare altro che impostare una riga del tipo

kernel /boot/vmlinuz-2.6.26-1-686 root=/dev/md0 init=/bin/sh

in modo che il kernel una volta caricato in memoria e impostato quelle 3 o 4 cose fondamentali avvi una shell; nei sistemi UNIX, nelle incarnazioni derivate dalla versione SystemV, il programma che avvia il sistema si chiama proprio init (che ha pid 0) che si preoccupa di avviare tutti gli altri processi (come indicato da inittab(1)) e che di solito sono in directory indicanti il runlevel (tipo rc2.d). Quindi indichiamo la shell sh come programma al posto di init (con il suo path of course) l’unico problema è che il filesystem viene montato read only e siccome è proprio il filesystem di root non è che lo posso smontare… usiamo l’opzione remount nella seguente maniera

mount -o remount,rw /dev/md0 /

(quando compare il prompt di sh of course) così da avere il nostro tree di directory adesso disponibili per un uso completo (nel mio server sto usando un RAID1 software in maniera da non perdere i miei dati all’improvviso, ecco perché quella strana indicazione md0, voi comuni user del desktop avrete qualcosa come sda1 per computer abbastanza moderni oppure hda1 nei casi rimasti al di fuori della casistiche precedenti). 

Adesso posso provare a vedere se il modulo lo carica, cosa che effettivamente avviene senza Ops, ma purtroppo non funge, si pianta al riavvio anche se indico di caricarlo prima (/etc/modules) oppure se lo metto in blacklist (/etc/modprobe.d/blacklist) e quindi come finale della storia ho smontato la scheda…