Chromium et /tmp

Bonsoir à tous,

Depuis quelques jours, ce qui correspondrait assez bien à la mise à jour du dix-sept novembre, ce bon Chromium me laisse quotidiennement des traces dans le /tmp, sous forme de répertoires comportant chacun trois fichiers, par exemple :

user@CHE:/tmp$ ls -aliF .org.chromium.Chromium.3lbhas total 44 1046529 drwx------ 2 user user 4096 nov. 28 17:09 ./ 2 drwxrwxrwt 12 root root 28672 nov. 28 17:48 ../ 1046531 -rw------- 1 user user 977 nov. 28 17:09 crl-set 1046532 -rw-r--r-- 1 user user 12 nov. 28 17:09 manifest.fingerprint 1046530 -rw------- 1 user user 34 nov. 28 17:09 manifest.json user@CHE:/tmp$
Dans ces trois fichiers, aucun indice qui saute aux yeux. Cela n’empêche nullement Chromium de marcher, mais ce /tmp à aller vider en permanence… Jamais pu trouver, également, de correlation entre l’apparition de l’un de ces trucs et un éventuel incident avec Chromium, site absent ou autre…

A+

Sergio

En même temps, /tmp c’est un peu fait pour (mettre des choses pas fondamentales dedans).
Tant que tu ne les vires pas pendant l’éxécution, il sera content. Et encore, il en gardera une trace tant que le fichier sera en cours d’utilisation par un processus, si je ne m’abuse.

Bien non, le machin reste là après que j’ai fermé ma session Chromium. Un jour j’en avais treize ou quatorze qui m’attendaient…

Soit 10Ko au total, bah …

Sinon, je ne connais pas la politique de vidage de /tmp, après un redémarrage de la machine ?

Oui, seulement je ne reboote jamais (disque SAS), tous les deux, trois mois peut-être…

Ce que je veux dire, c’est que c’est un peu collant, ce nouveau machin qui fait ce qu’il veut dans le dos sans que l’on sache trop pourquoi…

Alors le problème est tout autre :wink:

Si tu pars à la chasse de quoi qui fait quoi, il va falloir surveiller autre chose que les fichiers créés. Les connexions réseaux par exemple, ou le code source si tu as les compétences.

Si c’est l’effet anti-Google et anti-NSA qui te motive, tu peux épancher un peu de ta curiosité en lisant les remarques ici sur Chromium: github.com/nylira/prism-break/issues/169
(le site à l’origine de ces remarques: prism-break.org/ )

A noter que Firefox/Iceweasel n’est pas en reste, en incluant des pré-réglages et diverses Googleries.

Pourquoi tu ne montes pas /tmp en tmpfs?
Ca nécessite de la ram mais à chaque reboot le dossier est systématiquement raz.

[quote=“Triangle”]Pourquoi tu ne montes pas /tmp en tmpfs?
Ca nécessite de la ram mais à chaque reboot le dossier est systématiquement raz.[/quote]

+1

Soit dans /dev/shm ou un montage d’une partition “tmpfs” dans fstab.
Après faut de la ram, ce qui a priori ne pose pas trop de problème avec les machines actuelles.

perso, j’utilise tmpfs pour plein de choses …

[quote=“Triangle”]Pourquoi tu ne montes pas /tmp en tmpfs?
Ca nécessite de la ram mais à chaque reboot le dossier est systématiquement raz.[/quote]
Oui enfin sauf config très particulière, [mono]/tmp[/mono] est toujours vidé au reboot, [mono]tmpfs[/mono] ou pas.
Le problème de l’ami Sergio étant justement qu’il ne reboot pas souvent.

@Sergio Cela dit vu la taille ridicule des fichiers en question, l’espace disque total occupé par ce dossier doit être de 16ko. En supposant une 20aine par jour (mais qui ferme son navigateur 20 fois par jour ? si je le ferme 3 fois dans la journée c’est le bout du monde…) sur 3 mois ça fait un “énorme” :unamused: total de 28mo.
Je ne vois pas pourquoi tu t’en fais, mais si vraiment ça te travaille tu peux toujours mettre en place un [mono]cron[/mono] qui supprime tous les [mono]/tmp/.org.chromium.Chromium.*[/mono] vieux de plus d’une semaine. Ou bien rebooter plus souvent.

Tu peux très bien faire un script de 2 lignes :

  • la première ligne lance Chromium ;
  • la deuxième ligne efface le contenu de “/tmp”.

Quand tu veux lancer Chromium, tu lances ton script et comme ça dès que tu fermes Chromium le contenu de “/tmp” est effacé.

Simple, efficace.

[quote=“Cluxter”]Tu peux très bien faire un script de 2 lignes :

  • la première ligne lance Chromium ;
  • la deuxième ligne efface le contenu de “/tmp”.

Quand tu veux lancer Chromium, tu lances ton script et comme ça dès que tu fermes Chromium le contenu de “/tmp” est effacé.[/quote]
Ça risque de problème en cas de lancements multiples. Scénario :

  • Chromium est déjà ouvert
  • tu le réouvres ou un autre programme l’appelle pour ouvrir une URL
  • la deuxième instance redonne la main à la première, puis quitte immédiatement
  • tous les dossiers temporaires de Chromium sont effacés y compris ceux de la première instance
  • il se passe quoi là ?

D’où ma suggestion de cron qui ne supprime que les dossiers suffisamment anciens pour garantir qu’ils ne sont plus en cours d’utilisation.

Rebonsoir à tous, et merci pour tous vos avis.

Un détail, j’ouvre et ferme effectivement le navigateur vingt fois par jour, c’est-à-dire en utilisation normale, réservant la mise en icône à des manips ponctuelles et plus acrobatiques.

Bien sûr, il y a toutes les solutions par scripts et, bien sûr également, ce n’est pas la place que prend cette espèce de vérole qui est bien grave, mais le fait qu’en nombre elle défigure mon /tmp, où j’ai coutume d’aller encore assez souvent pour différentes raisons propres chacune à l’un ou l’autre de mes applicatifs.

Cela expliquerait peut-être le fait que je sois le premier à remarquer le phénomène : pas vieux, donc, qui coïnciderait bien avec cette mise à jour de Chromium le dix-sept novembre. En fait ce que je voudrais bien savoir, c’est cela, suis-je le seul avec Chromium et Wheezy à rencontrer cette chose ou non ?