[Debian] Ne pas effacer /tmp au boot

Le
Rémi Moyen
Salut,

Avec ma Debian testing, le répertoire /tmp (ainsi que /var/run et
/var/lock) est automatiquement vidé lorsque je reboote ma machine (je ne
sais pas exactement si c'est lorsque je l'éteins ou l'allume. Sans doute
au boot, d'après mes investigations suivantes, mais).

J'aimerais comprendre comment ça marche (par curiosité) et
optionellement comment je peux désactiver ce mécanisme pour /tmp.

Je soupçonne un script d'initialisation. Et en effet, en cherchant tous
les "tmp" dans /etc/init.d/, je trouve un script bootclean qui fait le
ménage. Il n'est pas appelé directement (dans aucun des rc*.d/), mais il
est invoqué par mountall-bootclean.sh et mountnfs-bootclean.sh.
Eux-mêmes sont appelés à un seul endroit, dans rcS.d (d'après inittab,
ce sont des scripts invoqués systématiquement au boot, avant d'appeler
les rc[1-6].d/ adaptés au runlevel).

Bon. En regardant le code de bootclean, je crois comprendre qu'un
fichier .clean dans chacun des trois répertoires sus-nommés est censé
éviter cet effacement :

[]
[ -d /tmp ] && ! [ -f /tmp/.clean ] && { clean_tmp || ES=1 ; }
[ -d /var/run ] && ! [ -f /var/run/.clean ] && { clean_run || ES=1 ; }
[ -d /var/lock ] && ! [ -f /var/lock/.clean ] && { clean_lock || ES=1 ; }
[]

(clean_tmp, clean_run et clean_lock font, entre autre, le ménage dans
chacun des trois répertoires en question)

(juste avant ces lignes il y a un test pour ne garder le .clean qui si
il est possédé par root, probablement pour éviter qu'un utilisateur
puisse fausser le mécanisme)

Notons qu'il existe aussi un script bootmisc.sh qui, entre autres
choses, efface ces .clean :

[]
# Remove bootclean's flag files.
# Don't run bootclean again after this!
rm -f /tmp/.clean /var/run/.clean /var/lock/.clean
[]

En l'occurrence, il n'est aussi invoqué que dans rcS.d, et *après*
mountall-bootclean.sh et mountnfs-bootclean.sh (qui invoquent bootclean) :
S36mountall-bootclean.sh
S46mountnfs-bootclean.sh
S55bootmisc.sh

Bon, tout ça m'a l'air compréhensible et assez logique. Sauf que

J'ai créé un .clean dans mon /tmp, en tant que root. J'ai rebooté. Et
mon /tmp s'est fait effacer comme d'habitude. J'ai pas vu de messages
suspects ou inhabituels dans les logs.

Uh ?

Quelqu'un a une idée, là ? Qu'est-ce que j'ai raté ?

Ai-je mal compris le mécanisme de nettoyage de /tmp ?
Ai-je mal mis en place mon .clean ?
Y'a-t-il un autre mécanisme qui fait le ménage derrière mon dos ?

Merci d'avance
--
Rémi Moyen
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Nicolas S.
Le #1878123
Salut,


Bonjour,

J'ai créé un .clean dans mon /tmp, en tant que root. J'ai rebooté. Et
mon /tmp s'est fait effacer comme d'habitude. J'ai pas vu de messages
suspects ou inhabituels dans les logs.

Uh ?

Quelqu'un a une idée, là ? Qu'est-ce que j'ai raté ?

Ai-je mal compris le mécanisme de nettoyage de /tmp ?
Ai-je mal mis en place mon .clean ?
Y'a-t-il un autre mécanisme qui fait le ménage derrière mon dos ?


Pour ça, un grep bien placé sur les fonctions de nettoyage (voire même
sur rm) devrait pouvoir donner la bonne réponse. Au pire, il faudrait
refaire le même test; à savoir, refaire un fichier /tmp/.clean et un
autre /tmp/témoin, puis redémarrer un à un tous les services du
runlevel incriminé.

Je penche plutôt pour un /tmp monté en mémoire, chose qui devient de
plus en plus systématique avec les distributions.

Comment est monté /tmp?

Rémi Moyen
Le #1878536
Nicolas S. wrote:

Tiens, une réponse ! Je ne m'y attendais plus, mais tant mieux :-)

J'ai créé un .clean dans mon /tmp, en tant que root. J'ai rebooté. Et
mon /tmp s'est fait effacer comme d'habitude. J'ai pas vu de messages
suspects ou inhabituels dans les logs.

Uh ?

Quelqu'un a une idée, là ? Qu'est-ce que j'ai raté ?

Ai-je mal compris le mécanisme de nettoyage de /tmp ?
Ai-je mal mis en place mon .clean ?
Y'a-t-il un autre mécanisme qui fait le ménage derrière mon dos ?


Pour ça, un grep bien placé sur les fonctions de nettoyage (voire même
sur rm) devrait pouvoir donner la bonne réponse. Au pire, il faudrait
refaire le même test; à savoir, refaire un fichier /tmp/.clean et un
autre /tmp/témoin, puis redémarrer un à un tous les services du
runlevel incriminé.


Bon, ça fait quelques semaines que j'avais joué avec ça, donc je ne me
rappelle plus de tous les détails, mais il me semble bien que j'avais
fait des grep dans /etc/init.d/ sur 'tmp' (et ensuite tracker les
quelques variables qui le contenaient et qui semblaient se rapporter à
ça, le cas échéant) et sur 'rm'. Il ne me semble pas avoir vu autre
chose que ce que je mentionnais dans mon message, mais j'ai pu rater des
choses.

Je (re-)regarderais de plus près dès que, euh, j'aurais moins la flemme ;-)

J'avais pas pensé à essayer les services un par un, c'est sans doute la
manière la plus simple de tester et d'identifier le truc sans rebooter
(encore que, une fois qu'il aura effacé tous les fichiers de session
spéciaux, y'aura peut-être un ou deux trucs bancals, mais bon, c'est pas
grave) !

Je penche plutôt pour un /tmp monté en mémoire, chose qui devient de
plus en plus systématique avec les distributions.

Comment est monté /tmp?


Il est sur la partition racine (oui, je sais, c'est pas idéal, mais
hein, bon), donc c'est pas ça. J'avoue que j'y avais pas pensé, c'était
une bonne piste pourtant !

Merci quand même...
--
Rémi Moyen


Landry MINOZA
Le #1878506
Rémi Moyen à écrit:

Nicolas S. wrote:

Tiens, une réponse ! Je ne m'y attendais plus, mais tant mieux :-)


Je viens de faire un grep -ri tmp * dans /etc/default, le fichier rcS fait
référence à une variable TMPTIME et au man rcS.
Dans ce dernier, on peut voir que TMPTIME définit l'age max (en jour) des
fichiers temporaire avant effacement. La valeur par défaut étant 0 :
toujours tous virer et la valeur -1 signifie : age infini.
Je n'ai pas eu le temps de tester (et surtout, je tiens à mon uptime :-)

--
Sed quis custodiet ipsos Custodes?

Rémi Moyen
Le #1878481
Landry MINOZA wrote:

Je viens de faire un grep -ri tmp * dans /etc/default, le fichier rcS fait
référence à une variable TMPTIME et au man rcS.


Bien vu ! Je n'avais pas du tout, mais alors pas du tout, pensé qu'il y
avait des trucs dans /etc/default...

Dans ce dernier, on peut voir que TMPTIME définit l'age max (en jour) des
fichiers temporaire avant effacement. La valeur par défaut étant 0 :
toujours tous virer et la valeur -1 signifie : age infini.


Oui, en effet, en relisant /etc/init.d/bootclean, je vois que c'est bien
ça qui devrait contrôler l'effacement. Apparemment, n'importe quelle
valeur négative ou les mots clés infinite et infinity ont le même effet :

case "$TMPTIME" in
-*|infinite|infinity)
[ "$VERBOSE" = no ] || log_action_end_msg 0 "skipped"
return 0
;;
esac

Et à la relecture, je vois mal comment j'ai pu interpréter le .clean
comme un truc à créer moi-même, c'est pourtant clair dans le script que
c'est un verrou local créé par le script lui-même...

Je n'ai pas eu le temps de tester (et surtout, je tiens à mon uptime :-)


Je comprends ça :-)
Merci pour l'info, ça me semble d'un seul coup logique. Je testerais,
mais je suis assez confiant, là.
--
Rémi Moyen

Publicité
Poster une réponse
Anonyme