~Breve riferimento ai comandi GNU/Linux

[commodoro]

forse questo fa al caso tuo.....


ps u -->Vediamo i parametri dell’utilizzo di memoria da parte dei
processi
• mostra le dimensioni della RAM utilizzata effettivamente (RSS)
• la percentuale utilizzata su quella totale (%MEM)
• la memoria virtuale utilizzata dal processo (VSZ):
vm_lib+vm_exe+vm_data+vm_stack
(vm_lib è lo spazio di memoria virtuale che occupano le librerie,
mentre vm_exe è quello occupato dall’eseguibile)

a te dovrebbe interessare il campo RSS!

[psimem]

Grazie ma forse mi sono espresso male io
Intendevo sapere ad esempio quanta ram occupa Amarok una volta lanciato

[Gimli[2BV!2B]]

Linea di comando specifica:

ps -FC NOME_PROCESSO

Quel che ti interessa dovrebbe essere l'RSS (come già affermato da commodoro).

Problema: il proceso di Amarok non si chiama amarok ma amarokapp. Questa mancata corrispondenza tra il nome del programma ed il processo vale per molti altri programmi grafici. Altro esempio: Firefox/Iceweasel=firefox-bin.

Sfruttando il fatto che di solito il nome del processo contiene quello del programma si può usare

ps aux | grep NOME_PROGRAMMA

In questo caso verrà tagliata la legenda delle colonne, ma RSS è sempre la sesta da sinistra.

Oppure si deve interrogare ps utilizzando l'opzione del PID del processo (ps -Fp PID), ma il PID o lo si conosce in partenza (processi figli o script o altro), oppure si può ricavare velocemente con ps aux | grep NOME_PROCESSO...

[psimem]

@commodoro / Gimli[2BV!2B]

quindi se:

psimem@psimem-desktop:~$ ps aux | grep firefox
psimem 25308 0.0 0.0 1752 524 pts/0 S 08:10 0:00 /bin/sh /usr/bin/firefox
psimem 25320 0.0 0.0 1756 532 pts/0 S 08:10 0:00 /bin/sh /usr/lib/firefox/run-mozilla.sh /usr/lib/firefox/firefox-bin
psimem 25324 11.7 4.4 210592 86440 pts/0 Sl 08:10 1:49 /usr/lib/firefox/firefox-bin
psimem 25822 0.0 0.0 2988 772 pts/0 S+ 08:26 0:00 grep firefox

significa che Firefox mi occupa 21M di ram?

[Gimli[2BV!2B]]

No, è la sesta colonna: 86440, circa 84MB...
210592 è la memoria virtuale, tutta quella "prenotata" dal processo (circa 205MB).

Come si sa Firefox 2 tende ad abbondare in memoria (il mio, aperto da meno di un'ora, ha già raggiunto i 95MB)...

[psimem]

Grazie chiarissimo: proprio cio' che mi serviva
Il mio di Firefox aperto da 15min con una sola scheda aperta pesa 65MB pero' ho un paio di estensioni caricate che penso siano abbastanza pesantucce

[frizzo28]

Ottima guida aggiunta ai preferiti...

uname -r ----> Visualizza la versione del kernel il uso

[Gimli[2BV!2B]]

Giusto, uname, non ci ho proprio pensato, grazie frizzo28!

[DeusEx]

Originariamente inviato da Gimli[2BV!2B]

kill -9 PID_PROCESSO_DA_TERMINARE -> Termina UN processo specifico, occorre ricavarne il pid con ps o top o altro.

qui c'è un'imprecisione: kill -9 PID_PROCESSO "uccide" il processo (che risulterà chiuso in modo anomalo, utile nel caso in cui il processo si è bloccato);
kill -15 PID_PROCESSO "termina" il processo in maniera corretta (se non è bloccato).

più in generale kill invia "segnali" ai processi;

il "-9" indica "ucciditi senza aspettare di finire quello che stai facendo", il "-15" invece "termina appena hai finito quello che stai facendo e salva quello che devi salvare".
Lo dico perchè in certe situazioni fà differenza usare l'uno o l'altro, e se il processo non è bloccato conviene sempre usare il "-15".

[iron84]

Originariamente inviato da DeusEx

qui c'è un'imprecisione: kill -9 PID_PROCESSO "uccide" il processo (che risulterà chiuso in modo anomalo, utile nel caso in cui il processo si è bloccato);
kill -15 PID_PROCESSO "termina" il processo in maniera corretta (se non è bloccato).

più in generale kill invia "segnali" ai processi;

il "-9" indica "ucciditi senza aspettare di finire quello che stai facendo", il "-15" invece "termina appena hai finito quello che stai facendo e salva quello che devi salvare".
Lo dico perchè in certe situazioni fà differenza usare l'uno o l'altro, e se il processo non è bloccato conviene sempre usare il "-15".

Grazie, non sapevo la differenza.

[Gimli[2BV!2B]]

Hai ragione DeusEx! Ora sistemo.

Mi chiedo se ci può stare bene un'introduzione ai segnali... ora ci penso.

[DeusEx]

Originariamente inviato da Gimli[2BV!2B]

Hai ragione DeusEx! Ora sistemo.

Mi chiedo se ci può stare bene un'introduzione ai segnali... ora ci penso.

potresti aggiungere "fdisk -l" per vedere le partizioni e i nomi dei dispositivi associati:
è utile per sapere il nome del dispositivo associato ad una certa partizione che poi si vuole montare con mount ( "mount /dev/sdXX /Directory_in_cui_montare") o direttamente con fstab

cmq bel lavoro!

[Gimli[2BV!2B]]

Grazie, ma devo dire che alla fine ce ne sono molte altre simili in giro...

Cerco solo di segnalare ciò di cui ho potuto provare l'utilità e di non trasformarlo un un inutile elenco (anche se ormai son varie pagine...).

Devo dire che sono stupito... un migliaio di visite! (Anche se probabilmente in molti sono fuggiti terrorizzati!)

[vizzz]

cercando di debuggare un software mi è venuto in soccorso un'opzione di grep veramente utile

"grep -r" oppure "rgrep"
che ricerca ricorsivamente una stringa a partire dalla posizione corrente in tutte le sottocartelle

rgrep stringa_da_cercare *

[Gimli[2BV!2B]]

Ottima vizzz!

Credo che sia molto più semplice raccogliere i comandi che non servono a nulla (da apt-get moo, ad aptitude -v moo, aptitude -vv moo... passando per yes e cowsay...).

[amd-novello]

Originariamente inviato da Gimli[2BV!2B]

Giusto, uname, non ci ho proprio pensato, grazie frizzo28!

molto meglio
uname -a

che mostra tutte le opzioni di uname senza star li a specificarle.

poi utile anche se non si ricorda la distribuzione installata

cat /etc/issue ------------------ normale e limitato
lsb_release -a -----------------con il nome in codice tipo feisty etc.

[Gimli[2BV!2B]]

Ci sta amd-novello, metterò un riferimento alla -a perché permette di avere una panoramica dei dati disponibili.

lsb_release fornisce informazioni che non hanno un uso molto pratico, non è nemmeno installato di default su alcune distribuzioni... ora vedo se trovo un posto che si possa addire ad /etc/issue.

[amd-novello]

Originariamente inviato da Gimli[2BV!2B]

Ci sta amd-novello, metterò un riferimento alla -a perché permette di avere una panoramica dei dati disponibili.

lsb_release fornisce informazioni che non hanno un uso molto pratico, non è nemmeno installato di default su alcune distribuzioni... ora vedo se trovo un posto che si possa addire ad /etc/issue.

per me è importantissimo perchè ameno di scriverlo sul muro non ricordo mai la versione di ubuntu che ho ma puo' essere un problema mio

[jeremy.83]

Non so se è il thread giusto, ma provo a metterlo qui.

Ultimamente ho avuto problemi nell'aggiornare la mia Debian Sid, a causa di un errore nel pacchetto "libdjvulibre". Per sistemare ho scovato questo workaround:

dpkg --force-overwrite -i /var/cache/apt/archives/pacchettonuovo.deb

Più che altro per segnalare un opzione di dpkg non particolarmente immediata e anche per uppare questa discussione che trovo utilissima e molto interessante (che metterei in rilievo ).

Ciao.

[Gimli[2BV!2B]]

Anch'io mi son trovato già tre volte con quel problema, ho risolto disinstallando il pacchetto vecchio con dpkg -P libdjvulibre15, poi la libdjvulibre21 andava su liscia.

Metterò un riferimento a --force-things perché qualche volta sono l'ultima spiaggia, ma considero quelle opzioni potenzialmente pericolose (credo di aver reso l'idea)...

Grazie del contributo, jeremy.83!