Ho cancellato la directory /tmp/

[Firetux]

più che d'accordo con Gallows! Lo svuotare /tmp all'arresto del sistema l'ho sempre fatto e non ho mai avuto un problema!

[zzt]

Semplicemente basta non cancellare i file nascosti:
una cosa è fare rm -fr /tmp (come penso abbia fatto Sh4DoW)
un'altra rm -fr /tmp/*
se non cancelli i file nascosti non avrai problemi con kde.

[gallows]

Semplicemente basta non cancellare i file nascosti:
una cosa è fare rm -fr /tmp (come penso abbia fatto Sh4DoW)
un'altra rm -fr /tmp/*
se non cancelli i file nascosti non avrai problemi con kde.

da rc.S:

Codice: Seleziona tutto

# Create /tmp/{.ICE-unix,.X11-unix} if they are not present:
if [ ! -e /tmp/.ICE-unix ]; then
  mkdir -p /tmp/.ICE-unix
  chmod 1777 /tmp/.ICE-unix
fi
if [ ! -e /tmp/.X11-unix ]; then
  mkdir -p /tmp/.X11-unix
  chmod 1777 /tmp/.X11-unix
fi

quindi non ci sono problemi..

[zzt]

No è perfetto... solo che questa soluzione non aveva funzionato per Sh4DoW, per un motivo molto semplice:
se cancelli /tmp/.ICE-unix, poi provi ad avviare KDE da utente normale, lo ricrei con owner=utente e non root e ad X non piace...

[Loris]

Confermo la citazione di Gallows, spesso pasticcio con gli SlackBuild e modifico tutti i file della /tmp in root.root risultato blocco di kde, il metodo più facile è un rm -rf /tmp/* e rm -rf /tmp/.* riavvio e tutto torna in ordine.

[phobos3576]

Meno male che nelle versioni recenti di rm è stata eliminata una clamorosa svista presente nelle vecchie versioni.
Osservate che la stringa .* è compatibile anche con . e ..
Quindi, con la vecchia versione di rm, un comando del tipo:

rm -rf /tmp/.*

cancella tutti i file nascosti presenti in /tmp, ma anche la directory corrente . ( rappresentata da /tmp ) e la directory superiore .. ( rappresentata, addirittura, dalla radice / )!!!
Con la nuova versione di rm compare, invece, un messaggio di errore che dice:

"Non posso cancellare . e .."

A parte questa curiosità "storica", vorrei chiedervi se la cancellazione delle directory nascoste /tmp/.ICE-unix e /tmp/X11-unix ( da rc.0 durante lo shutdown ) può creare problemi; nel mio caso, anche se le cancello vengono ricreate nel momento in cui lancio lo script startx.
In /usr/X11R6/bin/startx non vengono menzionate queste directory, per cui penso che vengano ricreate da KDE!
In ogni caso, tutto il contenuto di /tmp è temporaneo e viene utilizzato solo durante il funzionamento di Linux e delle varie applicazioni; non mi risulta che in /tmp ci siano dei file statici ( o directory statiche ) destinati ad esistere anche tra una sessione e l'altra di Linux.

Comunque, il dubbio rimane.

P.S.
In ogni caso, anch'io ho inserito in rc.0:

rm -rf /tmp/*
rm -rf /tmp/.*

e tutto funge!

[gallows]

forte la cosa dell'rm, non avevo mai provato
quelle directory sono importanti (vengono depositati i socket), perció è meglio che vengano cancellate allo shutdown per poi essere ricreate dallo script di pat... oppure lo fai tu con gli stessi permessi peró!
personalmente ho inserito rm -rf /tmp in rc.6 e sono tranquillo

[phobos3576]

forte la cosa dell'rm, non avevo mai provato
quelle directory sono importanti (vengono depositati i socket), perció è meglio che vengano cancellate allo shutdown per poi essere ricreate dallo script di pat... oppure lo fai tu con gli stessi permessi peró!
personalmente ho inserito rm -rf /tmp in rc.6 e sono tranquillo

Il vecchio problema di rm è citato anche nelle pagine di manuale (man rm), oltre che in numerosi testi su Linux.

[gallows]

no beh, conoscevo il rischio della potenziale distruzione dell'intero filesystem..
non sapevo del:

Codice: Seleziona tutto

> rm -ri .*
rm: impossibile rimuovere `.' o `..'

[useless]

pare che nella prox versione delle specifiche POSIX vogliano anche inserire che rm richieda un'ulteriore conferma quando si fa "rm -rf /". del resto chi mai, sano di mente, vorrebbe davvero eseguire un comando del genere!?

[Paoletta]

pare che nella prox versione delle specifiche POSIX vogliano anche inserire che rm richieda un'ulteriore conferma quando si fa "rm -rf /". del resto chi mai, sano di mente, vorrebbe davvero eseguire un comando del genere!?

metti che qualcuno sbagli a editare...del resto qualcuno in questi giorni,invece di scrivere:

#rm -f bin/

ha scritto:

#rm -f /bin

e la differenza è grossa...

[gallows]

metti che qualcuno sbagli a editare...del resto qualcuno in questi giorni,invece di scrivere:

#rm -f bin/

ha scritto:

#rm -f /bin

e la differenza è grossa...

quel comando non fa niente, il problema è -r

[Paoletta]

giusto,lo vedi che ho sbagliato a editare? :mrgreen:

[phobos3576]

Ha ragione Paoletta!

Anch'io, in un momento di coma profondo, per sbaglio ho dato il comando

rm -rf /tmp/.*

Se avessi avuto la vecchia versione di rm, avrei distrutto tutto il filesystem di Linux!!!

Qualche anno fa mi è capitata una cosa del genere mentre disinstallavo un programma con "make uninstall"; quello st**nzo che ha scritto il Makefile ha messo nello script un comando del tipo:

rm -rf /usr/local/directory_programma/.*

All'epoca c'era la vecchia versione di rm che, ovviamente, ha cancellato anche la directory corrente . (directory_programma) e quella superiore .. (cioè, l'intera /usr/local)!!!!

Comunque, tornando al discorso di /tmp/.ICE-unix e /tmp/.X11-unix, ho fatto degli esperimenti ed ho constatato che eliminando queste directory nascoste durante lo shutdown, al successivo riavvio tutto dipende da come ci si logga a Linux.
Se ci si logga come root, quando si lancia startx le directory nascoste vengono ricreate automaticamente.
Se ci si logga come utenti normali, quando si lancia il comando startx succede che X viene killato e compare il classico messaggio di errore: "ICE error, etc, etc".

Quindi, solo root può creare queste due directory!
Per risolvere il problema si può adottare la soluzione proposta da gallows; in alternativa, basta non cancellare da /tmp le directory nascoste (del resto, se sono nascoste vuol dire che non dovrebbero essere cancellate).

[useless]

@paoletta: certo, x questo è giusto chiedere conferma, xké quel comando lo puoi dare solo sbagliando a scrivere, è difficile che uno lo voglia dare coscientemente x davvero!