Supression des fichiers dans /tmp au démarrage

Support Debian
#1

Bonjour,

Pensant me servir du répertoire /tmp pour des fichiers temporaires-mais-pas-tant-que-ça (par exemple, les fichiers .part/.met de aMule), j’ai mis en place une partition de 20 Go, que je monte automatiquement sous /tmp.

Hors, j’ai constaté à mon dernier reboot que les fichiers placés dans le répertoire /tmp étaient effacés durant le démarrage de Linux … ARGH !

Je cherche donc le responsable de ce carnage, mais n’ai pas trouvé grand-chose pour l’instant (hormis un manuel du démarrage de Linux, extrêment précis mais qui ne m’a pas aidé).

Quelqu’un a une idée sur la question ?!

PS : Je sais qu’au moins une autre solution peut être envisagée pour contourner le problème : monter cette partition dans /home/tmp pour éviter l’effacement automatique dans /tmp. Mais cette solution ne me satisfait qu’à moitié, parce que du coup les fichiers temporaires seront écrits sur la partition racine (vu que je n’ai pas d’autre partition vide sous la main), qui n’a pas été taillée pour ça !

#2

:laughing: :laughing: :laughing: :laughing:
S’cuse-moi c’est pas méchant … :wink:

En fait, le /tmp est dédié aux fichiers temporaires du système et des processes utilisateurs. Il ne faut en aucun cas chercher a l’utiliser pour y stocker autre chose.

Tu veux connaître quel est le nom de “la conchita” qui fait le ménage à chaque reboot ? Le voici, et il est bien sûr câblé dans les scripts de démarrage de la machine:

#
# bootclean.sh  Functions to clean /tmp, /var/run and /var/lock.
#
# Version:      @(#)bootclean.sh  2.86-2  27-Aug-2004  miquels@cistron.nl
#

Il est toujours possible de le désactiver mais c’est FORTEMENT déconseillé…
Si tu le désactive, tu te retrouveras avec un merdier épouvantable sur ton système.

C’est la seule soluton à envisager. Ne mélangeons pas les données système et les données utilisateurs…

Tu arrête ton swap (voir la commande /sbin/swapoff) et tu repartitionne ton disque pour refaire les choses proprement.
:wink:
Mais bon, avec 20 GB tu as de la marge, rien ne presse. Documentes-toi pour refaire un système propre.

Tu peux envisager de faire par exemple, au moins un / un /var et un gros /home pour tes datas (pas dans /tmp … :smiley: )

#3

Merci pour cette réponse Jabba !
Ca correspond en gros à ce que je pensais.

Du coup j’envisage deux solutions :

  1. Modifier le bootclean.sh. Ne sautez pas au plafond comme ça, j’ai bouffé de la ligne de commande ksh et des scripts pendant un certain temps, et ne crains pas trop de faire une boulette. Pour info, il s’agirait simplement d’ajouter à la portion # # Only clean out /tmp if it is world-writable. This ensures # it really is a/the temp directory we're cleaning. # EXCEPT='! -name . ! ( -path ./lost+found -uid 0 ) ! ( -path ./quota.user -uid 0 ) ! ( -path ./aquota.user -uid 0 ) ! ( -path ./quota.group -uid 0 ) ! ( -path ./aquota.group -uid 0 ) ! ( -path ./.journal -uid 0 ) ! ( -path ./.clean -uid 0 ) ! ( -path './...security*' -uid 0 )'ceci :

# Rajouté par essaion le 2005-02-28 # Ne pas effacer le répertoire eMule et ses fichiers EXCEPT=$EXCEPT' ! -name "*.part*" ! -name "eMule"'
Bon, ça reste à tester mais le principe y est. Enfin bon, tant qu’à faire d’y être je ferai mieux de mettre au point un shell d’include, pour m’éviter de retaper dans le bootclean.sh à chaque exception que je veux mettre en place.

  1. Comme je ne suis quand même pas fanatique des solutions compliquées, j’aimerais assez appliquer la solution consistant à monter ma partition “temp” dans /home.
    Mon système compte actuellement les partitions suivantes :
  • /…1 Go
  • swap…1 Go
  • /var…1 Go
  • /usr…10 Go
  • /home…Plein de Go
    Compte tenu du fait que pour l’instant seuls 68 Mo sont occupés sur le fs racine, et que le /tmp ne compte pas plus de 100 ko de données, existe-t-il un gros risque de voir soudain la racine se remplir jusqu’à n’en plus pouvoir ?!
#4

[quote]Du coup j’envisage deux solutions :

  1. Modifier le bootclean.sh. Ne sautez pas au plafond comme ça, j’ai bouffé de la ligne de commande ksh et des scripts pendant un certain temps, et ne crains pas trop de faire une boulette. Pour info, il s’agirait simplement d’ajouter à la portion
    [/quote]
    Ben franchement, je te conseille pas …
    Je ne doute absolument pas de tes compétences en programmation mais à mon avis, il faut garder les scripts livrés par Debian, pour ce qu’ils sont: c’est à dire, des scripts de maintenance du système.
    idem pour l’arborescence standard. Pourquoi vouloir en détourner son usage pour faire autre chose que ce pour quoi elle est prévue ?
    Autre problème: et si un apt-get upgrade de ton système modifie le script en question. Ce problème là, tu le gère comment ?
    Pour ma part, j’utilise aMule dans sa configuration standard, tous les fichiers temporaires sont stockés dans l’arborescence du soft sous le directory .incoming et je trouve que ca fonctionne sans problème…
#5

Tu parle du /tmp dédié au système ?
Si c’est le cas, ce n’est pas non plus une très bonne idée. Ca peut marcher… jusqu’à ce que ca fasse planter un programme qui cherchait le /tmp dans la racine pour y stocker ses fichiers temporaires …

Ne complique pas … Et laisse le système de base dans sa configuration standard !

Si tu parles d’un directory dédié à tes téléchargements, tu peux effectivement lui réserver un directory où bon te semble… Et le /home me paraît en effet un bon choix :wink:

#6

Euh… Bon, d’accord, j’ai compris :slight_smile:
shame on me
Le coup de l’apt-get, je l’avais absolument pas envisagé.

Du coup, je vais faire mienne la philosophie “ce qui est au système reste au système” que tu évoques et monter mon tmp dans /home.
Ptêt même que je vais le repartitionner en un fragment pour /tmp et l’autre pour le /home/tmp, tiens.

Quand même, pour ma curiosité personnelle, t’aurais une idée de la volumétrie moyenne et de la croissance possible du /tmp ?!

#7

Encore une pt’ite correction:
Le soft est installé dans un répertoire standard et ensuite, un répertoire .aMule/ est créé dans le home directory de l’utilisateur qui a lancé amule.
Ca donne quelque chose comme:

/home/toto/.aMule/.Incoming

#8

Ok pour aMule et son arborescence.

… je suis en cours de réflexion intense sur le pourquoi d’un cloisonnement par utilisateur (genre, le .aMule dans les répertoires utilisateurs) quand le système n’est censé être utilisé que par un ou deux utilisateurs… et dans ce cas précis, quand in n’est pas prévu de lancer plus d’une session de aMule en simultané.

… Simplement pour prendre de bonnes habitudes ? (ce serait déjà une bonne idée, je ne dis pas le contraire :slight_smile: ).

–
Aurélien

PS : non, je ne cherche pas à décaler le /tmp ailleurs qu’à la racine ; je parlais bien de ne décaler que ma partition de stockage temporaire, pas le répertoire logique. Mais c’était bien de s’en inquiéter (j’ose à peine imaginer le désastre potentiel derrière une telle manip).

#9

En principe plutôt négligeable. Enfin ca dépend de la charge de ton système.

Tiens, au hasard je te montre un DIGITAL UNIX qui tourne non-stop depuis 800 jours …

[quote]lille-root# uptime
15:23 up 802 days, 4:17, 4 users, load average: 0.00, 0.00, 0.00
lille-root#
[/quote]
(oui, oui Monsieur, j’en suis fier …:slightly_smiling:

Sur cette machine, j’ai des bases Oracle, des ldap et autres serveurs web qui tournent et voilà en kb l’occupation de /tmp :

Ceci dit, cette machine ne démarre que des applis en mode texte. Donc y aura toujours plus de merde dans /tmp si tu démarres 10 session de openoffice et 20 Gimp et 30 mozilla en même temps …
:smiley:

#10

Ok, merci pour les infos !
(et oui, je crois aussi que tu peux être fier de tes 800 jours de up ! WOUAH ! Tiens, ça mérite même une “frimousse” (ou “émoticone”, je suis perdu avec tous ces nouveaux termes français), une fois n’est pas coutume : :open_mouth: )

Du coup, je ne vais pas chercher plus loin, et monter ma partition dans /home/tmp, en laissant le /tmp sur ma partition racine. Si tout pète un jour pour cause de croissance désordonnée, j’aviserai.

Encore merci pour tes réponses patientes et conseils.

#11

Tout simplement parce que Linux est dérivé d’Unix et que Unix est un vrai système multi-utilisateurs, multi-tâches et multi tout ce qu tu voudras … :open_mouth:

Je te l’accorde, c’est une philosophie différente de ce qui se voit sur d’autres OS …

You are welcome ! :wink:

#12

Je me permets d’intervenir brièvement pour mettre un bémol aux cris d’orfraie de Jabba.
Quand on atteint un certain niveau de compètence, l’intègration de petits “hacks” dans les scripts systèmes est loin d’être interdit par la philosophie et la logique de développement GNU.
C’est même à ca que servent les clauses de liberté de modification du code, et c’est un des atouts techniques que procure le libre: quand on à besoin, on fait, et on a de compte à rendre à personne.
Et quand on est fier, on redistribue ce qu’on a fait.
C’est comme ca que ca avance.

Et j’ajouterais que l’idée d’inclure la lecture d’un fichier de config dans le script “bootclean.sh” me parait relativement canonique, et de bon aloi. A tester et proposer à l’équipe qui s’occupe du script, pour integration dans une future release. Le risque avec l’include (ou les ‘source’) c’est qu’un utilisateur mal intentionné ayant accés au fichier inclus peut injecter des commandes dans ce fichier et les faire executer par le script appelant => faille. Il vaut toujours mieux lire un fichier de config qu’un executable même scripté :slightly_smiling: …

Il n’est pas dit, sinon, qu’une modif effectuée sur ce script “bootclean.sh” soit écrasé en cas de mise à jour du paquet le concernant. apt implémente une logique de protection assez fine des installation de fichiers - basé sur les signatures md5 pour voir si les fichiers ont été modifiés - et il se peut que le fichier ne soit plus mis à jour si il a été modifié. Pensez à la modif manuelle du XF86config et à sa gestion par dpkg-reconfigure.

#13

Koi ? :smiling_imp:

Déjà, c’est koi un orfraie ?

Si tu regardes ma photo, tu vois ke je ressemble plus à une limace géante qu’a un orfraie, non ? :open_mouth:

Mouais, bon admettons, MattOTop n’a pas tort … :slightly_smiling: J’ai tellement l’habitude de bosser dans des environnements Unix propriétaires et blindés par des contrats de support interdisant ce genre de “personnalisation” que j’en oublie un des avantages majeurs de Linux/GNU… :blush:

Mais bon, grrrmblbmm… On ne m’enlèvera pas de l’idée que ce genre de manip. risquerait de déstabiliser le système.
Et surtout le fait que de bricoler dans /tmp alors qu’on peut faire ce qu’on veut dans /home est totalement inutile dans le cas présent.

#14

Voilà, j’ai fini par rebooter avec KNOPPIX, monter te démarrer les grappes RAID qui allaient bien, et modifier le fstab pour monter ma partition “temporaire” dans /home/tmp,

Au reboot, le système a moyennement apprécié : gdm me disait que ma session avait duré moins de 10 secondes et qu’il y avait un truc qui clochait (perspicace, gdm). Le message d’erreur détaillé semblait montrer un problème de droit. Vite, une console root, et que vois-je ? Le /tmp ne donnait les droits en écriture qu’à son propriétaire (root). Curieux quand même, parce que les droits devaient être les mêmes quand la partition temporaire était montée dans /tmp ?!

Enfin bon, je confirme : déplacer le /tmp serait VRAIMENT une mauvaise initiative.

Une orfraie ?
Bah, euh…man orfraieAh tiens, ça marche pô ?!
Nan, il s’agit d’une chouette,… Euh… ah nan tiens, c’est vrai, je confonds systématiquement avec effraie, maintenant que je me rappelle.
recherche sous Google
Un(e?) orfraie est un fait une espèce d’aigle pêcheur, et il semble que son cri ne soit pas strident. D’après cette page, la langue française confonds depuis bien longtemps avec l’effraie, qui est elle une chouette au cri perçant (je suis rassuré : si même la langue française confonds, j’ai une bonne excuse).

Merci pour ton intervention Matt, je place l’idée de parser un fichier de conf dans ma [i]to-do list[i], en N+8… Puisque j’ai déjà 7 autres points qui se sont rajoutés depuis hier :frowning: