Bonsoir,
tout est dans la question !Une fois que
les logiciels sont installés, peut-on supprimer
le contenu de /tmp ( j'ai l'habitude d'y loger
les tar.gz que je télécharge )
Merci,
Jacopo
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Jerome Lambert
Le Mon, 09 Aug 2004 22:06:37 +0200, jacopo a écrit :
Bonsoir,
Bonsoir,
tout est dans la question !Une fois que les logiciels sont installés, peut-on supprimer le contenu de /tmp ( j'ai l'habitude d'y loger les tar.gz que je télécharge )
Oui.
Si je ne m'abuse, il y a/avait une option "quelque part" pour le vider automatiquement au démarrage.
-- Jerome "Moi, je trouve ça rigolo quand y a un truc qui marche pas avec Linux. Chercher à le faire marcher m'amuse beaucoup. C'est mieux qu'un jeu vidéo." M. in fr.comp.os.linux.debats
Le Mon, 09 Aug 2004 22:06:37 +0200, jacopo a écrit :
Bonsoir,
Bonsoir,
tout est dans la question !Une fois que
les logiciels sont installés, peut-on supprimer
le contenu de /tmp ( j'ai l'habitude d'y loger
les tar.gz que je télécharge )
Oui.
Si je ne m'abuse, il y a/avait une option "quelque part" pour le vider
automatiquement au démarrage.
--
Jerome
"Moi, je trouve ça rigolo quand y a un truc qui marche pas avec Linux.
Chercher à le faire marcher m'amuse beaucoup. C'est mieux qu'un jeu vidéo."
M. in fr.comp.os.linux.debats
Le Mon, 09 Aug 2004 22:06:37 +0200, jacopo a écrit :
Bonsoir,
Bonsoir,
tout est dans la question !Une fois que les logiciels sont installés, peut-on supprimer le contenu de /tmp ( j'ai l'habitude d'y loger les tar.gz que je télécharge )
Oui.
Si je ne m'abuse, il y a/avait une option "quelque part" pour le vider automatiquement au démarrage.
-- Jerome "Moi, je trouve ça rigolo quand y a un truc qui marche pas avec Linux. Chercher à le faire marcher m'amuse beaucoup. C'est mieux qu'un jeu vidéo." M. in fr.comp.os.linux.debats
Hervé Riboulot
Le Mon, 09 Aug 2004 22:08:38 +0200, Jerome Lambert a écrit :
Le Mon, 09 Aug 2004 22:06:37 +0200, jacopo a écrit :
Bonsoir,
Bonsoir,
tout est dans la question !Une fois que les logiciels sont installés, peut-on supprimer le contenu de /tmp ( j'ai l'habitude d'y loger les tar.gz que je télécharge )
Oui.
Si je ne m'abuse, il y a/avait une option "quelque part" pour le vider automatiquement au démarrage.
Pour Mandrake:
Centre de Contrôle Mandrake -> Gestionnaire de démarrage -> avancé (cocher la case 'vider le dossier /tmp à chaque démarrage'.
Il est aussi possible de vider ce dossier sur un critère de volume.
Le Mon, 09 Aug 2004 22:08:38 +0200, Jerome Lambert a écrit :
Le Mon, 09 Aug 2004 22:06:37 +0200, jacopo a écrit :
Bonsoir,
Bonsoir,
tout est dans la question !Une fois que
les logiciels sont installés, peut-on supprimer
le contenu de /tmp ( j'ai l'habitude d'y loger
les tar.gz que je télécharge )
Oui.
Si je ne m'abuse, il y a/avait une option "quelque part" pour le vider
automatiquement au démarrage.
Pour Mandrake:
Centre de Contrôle Mandrake -> Gestionnaire de démarrage -> avancé
(cocher la case 'vider le dossier /tmp à chaque démarrage'.
Il est aussi possible de vider ce dossier sur un critère de volume.
Le Mon, 09 Aug 2004 22:08:38 +0200, Jerome Lambert a écrit :
Le Mon, 09 Aug 2004 22:06:37 +0200, jacopo a écrit :
Bonsoir,
Bonsoir,
tout est dans la question !Une fois que les logiciels sont installés, peut-on supprimer le contenu de /tmp ( j'ai l'habitude d'y loger les tar.gz que je télécharge )
Oui.
Si je ne m'abuse, il y a/avait une option "quelque part" pour le vider automatiquement au démarrage.
Pour Mandrake:
Centre de Contrôle Mandrake -> Gestionnaire de démarrage -> avancé (cocher la case 'vider le dossier /tmp à chaque démarrage'.
Il est aussi possible de vider ce dossier sur un critère de volume.
Jérémy JUST
On Mon, 09 Aug 2004 22:13:46 +0200 Hervé Riboulot wrote:
Pour Mandrake:
Centre de Contrôle Mandrake -> Gestionnaire de démarrage -> avancé (cocher la case 'vider le dossier /tmp à chaque démarrage'.
Il est aussi possible de vider ce dossier sur un critère de volume.
Et par défaut, les fichiers non *accédés* depuis 10 jours sont supprimés (je viens de le vérifier à mes dépends), et ça se modifie dans /etc/cron.daily/tmpwatch
-- Jérémy JUST
On Mon, 09 Aug 2004 22:13:46 +0200
Hervé Riboulot <herve.riboulot@wanadoo.fr.invalid> wrote:
Pour Mandrake:
Centre de Contrôle Mandrake -> Gestionnaire de démarrage -> avancé
(cocher la case 'vider le dossier /tmp à chaque démarrage'.
Il est aussi possible de vider ce dossier sur un critère de volume.
Et par défaut, les fichiers non *accédés* depuis 10 jours sont
supprimés (je viens de le vérifier à mes dépends), et ça se modifie dans
/etc/cron.daily/tmpwatch
On Mon, 09 Aug 2004 22:13:46 +0200 Hervé Riboulot wrote:
Pour Mandrake:
Centre de Contrôle Mandrake -> Gestionnaire de démarrage -> avancé (cocher la case 'vider le dossier /tmp à chaque démarrage'.
Il est aussi possible de vider ce dossier sur un critère de volume.
Et par défaut, les fichiers non *accédés* depuis 10 jours sont supprimés (je viens de le vérifier à mes dépends), et ça se modifie dans /etc/cron.daily/tmpwatch
-- Jérémy JUST
Pierre FERSING
Le Tue, 10 Aug 2004 02:29:52 +0200, TiChou a écrit :
Et par défaut, les fichiers non *accédés* depuis 10 jours sont supprimés (je viens de le vérifier à mes dépends), et ça se modifie dans /etc/cron.daily/tmpwatch
Ce qui est vraiment n'importe quoi !
Et pourquoi c'est n'importe quoi? Ce sont des fichiers temporaire qu'il y a dans /tmp d'où sont nom. De plus il peuvent être supprimé selon le critère choisit par l'administrateur (cf FHS "data stored in /tmp may be deleted in a site-specific manner")
Le Tue, 10 Aug 2004 02:29:52 +0200, TiChou a écrit :
Et par défaut, les fichiers non *accédés* depuis 10 jours sont
supprimés (je viens de le vérifier à mes dépends), et ça se modifie dans
/etc/cron.daily/tmpwatch
Ce qui est vraiment n'importe quoi !
Et pourquoi c'est n'importe quoi?
Ce sont des fichiers temporaire qu'il y a dans /tmp d'où sont nom. De
plus il peuvent être supprimé selon le critère choisit par
l'administrateur (cf FHS "data stored in /tmp may be deleted in a
site-specific manner")
Le Tue, 10 Aug 2004 02:29:52 +0200, TiChou a écrit :
Et par défaut, les fichiers non *accédés* depuis 10 jours sont supprimés (je viens de le vérifier à mes dépends), et ça se modifie dans /etc/cron.daily/tmpwatch
Ce qui est vraiment n'importe quoi !
Et pourquoi c'est n'importe quoi? Ce sont des fichiers temporaire qu'il y a dans /tmp d'où sont nom. De plus il peuvent être supprimé selon le critère choisit par l'administrateur (cf FHS "data stored in /tmp may be deleted in a site-specific manner")
TiChou
Dans le message <news:, *Pierre FERSING* tapota sur f.c.o.l.configuration :
Et par défaut, les fichiers non *accédés* depuis 10 jours sont
Une remarque au passage : on recommande vivement de monter la partition /tmp avec l'option noatime...
supprimés (je viens de le vérifier à mes dépends), et ça se modifie dans /etc/cron.daily/tmpwatch
Ce qui est vraiment n'importe quoi !
Et pourquoi c'est n'importe quoi?
Ça me semble évident...
Ce sont des fichiers temporaire qu'il y a dans /tmp d'où sont nom.
Qui sont créés par des applications... et qui ne devraient être supprimés uniquement par les applications qui les ont créés. Bien sûr, une application peut s'arrêter de façon innatendue ou être mal programmée et alors ne pas supprimer les fichiers temporaires qu'elle a créé. Et, à part l'expérience de l'administrateur et encore dans une certaine mesure, aucun script ou programme ne devrait être en droit de décider si un fichier dans /tmp est orphelin ou non et par conséquent s'il doit être supprimé ou non. Et penser qu'un fichier temporaire dont la date de modification ou la date de dernier accès aurait plus de 10 jours, pourrait être considéré comme un fichier orphelin est là aussi du n'importe quoi. Qu'est ce qui permet de dire que ce fichier n'est plus ou ne sera plus utile à l'application qui l'a créé ? J'ai un tas de fichiers vérous, sessions, log et divers qui ont plus de 10 jours et qui ne sont pas obligatoirement à l'état ouvert, et pourtant les applications qui les ont créé tournent toujours et par expérience je sais qu'elles en ont encore besoin... Qu'ils soient effacés au prochain redémarrage, pourquoi pas si c'est fait comme il faut, mais les supprimer alors que les applications tournent toujours...
De plus il peuvent être supprimé selon le critère choisit par l'administrateur (cf FHS "data stored in /tmp may be deleted in a site-specific manner")
Ce qui ne veut pas dire que le critère décidé par l'adminsitrateur doit être fantaisiste.
Et une dernière remarque concernant le post initial : /tmp n'est pas un lieu de stockage ne serait-ce que pour des raisons évidentes de sécurités !
-- TiChou
Dans le message <news:pan.2004.08.10.07.42.45.299188@wanadoo.fr>,
*Pierre FERSING* tapota sur f.c.o.l.configuration :
Et par défaut, les fichiers non *accédés* depuis 10 jours sont
Une remarque au passage : on recommande vivement de monter la partition /tmp
avec l'option noatime...
supprimés (je viens de le vérifier à mes dépends), et ça se modifie dans
/etc/cron.daily/tmpwatch
Ce qui est vraiment n'importe quoi !
Et pourquoi c'est n'importe quoi?
Ça me semble évident...
Ce sont des fichiers temporaire qu'il y a dans /tmp d'où sont nom.
Qui sont créés par des applications... et qui ne devraient être supprimés
uniquement par les applications qui les ont créés.
Bien sûr, une application peut s'arrêter de façon innatendue ou être mal
programmée et alors ne pas supprimer les fichiers temporaires qu'elle a
créé. Et, à part l'expérience de l'administrateur et encore dans une
certaine mesure, aucun script ou programme ne devrait être en droit de
décider si un fichier dans /tmp est orphelin ou non et par conséquent s'il
doit être supprimé ou non.
Et penser qu'un fichier temporaire dont la date de modification ou la date
de dernier accès aurait plus de 10 jours, pourrait être considéré comme un
fichier orphelin est là aussi du n'importe quoi. Qu'est ce qui permet de
dire que ce fichier n'est plus ou ne sera plus utile à l'application qui l'a
créé ?
J'ai un tas de fichiers vérous, sessions, log et divers qui ont plus de 10
jours et qui ne sont pas obligatoirement à l'état ouvert, et pourtant les
applications qui les ont créé tournent toujours et par expérience je sais
qu'elles en ont encore besoin... Qu'ils soient effacés au prochain
redémarrage, pourquoi pas si c'est fait comme il faut, mais les supprimer
alors que les applications tournent toujours...
De plus il peuvent être supprimé selon le critère choisit par
l'administrateur (cf FHS "data stored in /tmp may be deleted in a
site-specific manner")
Ce qui ne veut pas dire que le critère décidé par l'adminsitrateur doit être
fantaisiste.
Et une dernière remarque concernant le post initial : /tmp n'est pas un lieu
de stockage ne serait-ce que pour des raisons évidentes de sécurités !
Dans le message <news:, *Pierre FERSING* tapota sur f.c.o.l.configuration :
Et par défaut, les fichiers non *accédés* depuis 10 jours sont
Une remarque au passage : on recommande vivement de monter la partition /tmp avec l'option noatime...
supprimés (je viens de le vérifier à mes dépends), et ça se modifie dans /etc/cron.daily/tmpwatch
Ce qui est vraiment n'importe quoi !
Et pourquoi c'est n'importe quoi?
Ça me semble évident...
Ce sont des fichiers temporaire qu'il y a dans /tmp d'où sont nom.
Qui sont créés par des applications... et qui ne devraient être supprimés uniquement par les applications qui les ont créés. Bien sûr, une application peut s'arrêter de façon innatendue ou être mal programmée et alors ne pas supprimer les fichiers temporaires qu'elle a créé. Et, à part l'expérience de l'administrateur et encore dans une certaine mesure, aucun script ou programme ne devrait être en droit de décider si un fichier dans /tmp est orphelin ou non et par conséquent s'il doit être supprimé ou non. Et penser qu'un fichier temporaire dont la date de modification ou la date de dernier accès aurait plus de 10 jours, pourrait être considéré comme un fichier orphelin est là aussi du n'importe quoi. Qu'est ce qui permet de dire que ce fichier n'est plus ou ne sera plus utile à l'application qui l'a créé ? J'ai un tas de fichiers vérous, sessions, log et divers qui ont plus de 10 jours et qui ne sont pas obligatoirement à l'état ouvert, et pourtant les applications qui les ont créé tournent toujours et par expérience je sais qu'elles en ont encore besoin... Qu'ils soient effacés au prochain redémarrage, pourquoi pas si c'est fait comme il faut, mais les supprimer alors que les applications tournent toujours...
De plus il peuvent être supprimé selon le critère choisit par l'administrateur (cf FHS "data stored in /tmp may be deleted in a site-specific manner")
Ce qui ne veut pas dire que le critère décidé par l'adminsitrateur doit être fantaisiste.
Et une dernière remarque concernant le post initial : /tmp n'est pas un lieu de stockage ne serait-ce que pour des raisons évidentes de sécurités !
-- TiChou
Nicolas George
"TiChou" wrote in message :
Une remarque au passage : on recommande vivement de monter la partition /tmp avec l'option noatime...
Ça dépend fortement des cas. Mon /tmp en tmpfs, je ne vois pas grand intérêt de le mettre en noatime :-Þ
Qui sont créés par des applications... et qui ne devraient être supprimés uniquement par les applications qui les ont créés. Bien sûr, une application peut s'arrêter de façon innatendue ou être mal programmée et alors ne pas supprimer les fichiers temporaires qu'elle a créé. Et, à part l'expérience de l'administrateur et encore dans une certaine mesure, aucun script ou programme ne devrait être en droit de décider si un fichier dans /tmp est orphelin ou non et par conséquent s'il doit être supprimé ou non.
Attention, tu fais ici une erreur classique : confondre ce qui devrait être et ce qui est. En théorie, peut-être, /tmp ne devrait être accédé que par des applications¹, et donc ne pas nécessiter de ménage. Mais dans la pratique, il ne l'est pas. Il y a des gens qui vont y copier des fichiers avant transfert ailleurs (style scp foo:bar /tmp; sudo cp /tmp/bar /usr/local/...), ou extraire un tarball pour examiner rapidement quelques fichiers, etc., et laisser tout ça en plan. Ces gens-là sont une réalité, il est donc nécessaire de s'y adapter.
1 : Ce point, d'ailleurs, est très douteux. Quand l'espace disque durable (/home) est limité (beaucoup de compts, quota bas), ou lent (NFS), avoir un espace local pour des données qui n'ont besoin de rester que quelques heures est très précieux. Et ça fait fortement groumpfer si toute la place est déjà prise.
D'un certain point de vue, tu peux considérer que l'utilisateur-en-train- de-faire-quelque-chose est une application qui utilise des fichiers temporaires. Application qui plus est buggée, car elle oublie souvent de supprimer les fichiers dont elle a eu besoin. Et comme il n'est pas envisageable de corriger l'application en question, il faut adapter le système.
J'ai un tas de fichiers vérous, sessions, log et divers qui ont plus de 10 jours et qui ne sont pas obligatoirement à l'état ouvert, et pourtant les applications qui les ont créé tournent toujours et par expérience je sais qu'elles en ont encore besoin... Qu'ils soient effacés au prochain redémarrage, pourquoi pas si c'est fait comme il faut, mais les supprimer alors que les applications tournent toujours...
Dans ce cas, j'ai tendence à dire qu'il conviendrait de les mettre ailleurs, dans un répertoire qui leur est propre, et que d'autres utilisateurs ne viennent pas polluer de leur bordel.
Évidemment, ça dépend énormément de l'usage qui est fait de la machine : sur un pur serveur (web et/ou mail et/ou n'importe quoi), il n'y a pas de problème de ce genre. Mais dès que tu acceptes des logins d'utilisaturs, ça devient totalement différent.
"TiChou" wrote in message <pwet.20040810095409@florizarre.tichou.org>:
Une remarque au passage : on recommande vivement de monter la partition /tmp
avec l'option noatime...
Ça dépend fortement des cas. Mon /tmp en tmpfs, je ne vois pas grand
intérêt de le mettre en noatime :-Þ
Qui sont créés par des applications... et qui ne devraient être supprimés
uniquement par les applications qui les ont créés.
Bien sûr, une application peut s'arrêter de façon innatendue ou être mal
programmée et alors ne pas supprimer les fichiers temporaires qu'elle a
créé. Et, à part l'expérience de l'administrateur et encore dans une
certaine mesure, aucun script ou programme ne devrait être en droit de
décider si un fichier dans /tmp est orphelin ou non et par conséquent s'il
doit être supprimé ou non.
Attention, tu fais ici une erreur classique : confondre ce qui devrait
être et ce qui est. En théorie, peut-être, /tmp ne devrait être accédé
que par des applications¹, et donc ne pas nécessiter de ménage. Mais
dans la pratique, il ne l'est pas. Il y a des gens qui vont y copier des
fichiers avant transfert ailleurs (style scp foo:bar /tmp; sudo cp
/tmp/bar /usr/local/...), ou extraire un tarball pour examiner
rapidement quelques fichiers, etc., et laisser tout ça en plan. Ces
gens-là sont une réalité, il est donc nécessaire de s'y adapter.
1 : Ce point, d'ailleurs, est très douteux. Quand l'espace disque
durable (/home) est limité (beaucoup de compts, quota bas), ou lent
(NFS), avoir un espace local pour des données qui n'ont besoin de rester
que quelques heures est très précieux. Et ça fait fortement groumpfer si
toute la place est déjà prise.
D'un certain point de vue, tu peux considérer que l'utilisateur-en-train-
de-faire-quelque-chose est une application qui utilise des fichiers
temporaires. Application qui plus est buggée, car elle oublie souvent de
supprimer les fichiers dont elle a eu besoin. Et comme il n'est pas
envisageable de corriger l'application en question, il faut adapter le
système.
J'ai un tas de fichiers vérous, sessions, log et divers qui ont plus de 10
jours et qui ne sont pas obligatoirement à l'état ouvert, et pourtant les
applications qui les ont créé tournent toujours et par expérience je sais
qu'elles en ont encore besoin... Qu'ils soient effacés au prochain
redémarrage, pourquoi pas si c'est fait comme il faut, mais les supprimer
alors que les applications tournent toujours...
Dans ce cas, j'ai tendence à dire qu'il conviendrait de les mettre
ailleurs, dans un répertoire qui leur est propre, et que d'autres
utilisateurs ne viennent pas polluer de leur bordel.
Évidemment, ça dépend énormément de l'usage qui est fait de la machine :
sur un pur serveur (web et/ou mail et/ou n'importe quoi), il n'y a pas
de problème de ce genre. Mais dès que tu acceptes des logins
d'utilisaturs, ça devient totalement différent.
Une remarque au passage : on recommande vivement de monter la partition /tmp avec l'option noatime...
Ça dépend fortement des cas. Mon /tmp en tmpfs, je ne vois pas grand intérêt de le mettre en noatime :-Þ
Qui sont créés par des applications... et qui ne devraient être supprimés uniquement par les applications qui les ont créés. Bien sûr, une application peut s'arrêter de façon innatendue ou être mal programmée et alors ne pas supprimer les fichiers temporaires qu'elle a créé. Et, à part l'expérience de l'administrateur et encore dans une certaine mesure, aucun script ou programme ne devrait être en droit de décider si un fichier dans /tmp est orphelin ou non et par conséquent s'il doit être supprimé ou non.
Attention, tu fais ici une erreur classique : confondre ce qui devrait être et ce qui est. En théorie, peut-être, /tmp ne devrait être accédé que par des applications¹, et donc ne pas nécessiter de ménage. Mais dans la pratique, il ne l'est pas. Il y a des gens qui vont y copier des fichiers avant transfert ailleurs (style scp foo:bar /tmp; sudo cp /tmp/bar /usr/local/...), ou extraire un tarball pour examiner rapidement quelques fichiers, etc., et laisser tout ça en plan. Ces gens-là sont une réalité, il est donc nécessaire de s'y adapter.
1 : Ce point, d'ailleurs, est très douteux. Quand l'espace disque durable (/home) est limité (beaucoup de compts, quota bas), ou lent (NFS), avoir un espace local pour des données qui n'ont besoin de rester que quelques heures est très précieux. Et ça fait fortement groumpfer si toute la place est déjà prise.
D'un certain point de vue, tu peux considérer que l'utilisateur-en-train- de-faire-quelque-chose est une application qui utilise des fichiers temporaires. Application qui plus est buggée, car elle oublie souvent de supprimer les fichiers dont elle a eu besoin. Et comme il n'est pas envisageable de corriger l'application en question, il faut adapter le système.
J'ai un tas de fichiers vérous, sessions, log et divers qui ont plus de 10 jours et qui ne sont pas obligatoirement à l'état ouvert, et pourtant les applications qui les ont créé tournent toujours et par expérience je sais qu'elles en ont encore besoin... Qu'ils soient effacés au prochain redémarrage, pourquoi pas si c'est fait comme il faut, mais les supprimer alors que les applications tournent toujours...
Dans ce cas, j'ai tendence à dire qu'il conviendrait de les mettre ailleurs, dans un répertoire qui leur est propre, et que d'autres utilisateurs ne viennent pas polluer de leur bordel.
Évidemment, ça dépend énormément de l'usage qui est fait de la machine : sur un pur serveur (web et/ou mail et/ou n'importe quoi), il n'y a pas de problème de ce genre. Mais dès que tu acceptes des logins d'utilisaturs, ça devient totalement différent.
Vincent Bernat
OoO En cette matinée pluvieuse du mardi 10 août 2004, vers 10:58, "TiChou" disait:
J'ai un tas de fichiers vérous, sessions, log et divers qui ont plus de 10 jours et qui ne sont pas obligatoirement à l'état ouvert, et pourtant les applications qui les ont créé tournent toujours et par expérience je sais qu'elles en ont encore besoin...
Il faut alors corriger ces applications pour qu'elles utilisent /var/lock, /var/run et /var/log pour faire ceci. Avoir de l'espace libre dans /tmp est crucial (un système peut être entièrement immobilisé si les applis ne peuvent plus écrire de fichiers temporaires) et il est donc très commun d'en effacer les vieux fichiers. C'est d'ailleurs inscrit dans la norme POSIX ! Et rappelé dans la FHS. -- panic("bad_user_access_length executed (not cool, dude)"); 2.0.38 /usr/src/linux/kernel/panic.c
OoO En cette matinée pluvieuse du mardi 10 août 2004, vers 10:58,
"TiChou" <gro.uohcit@uohcit> disait:
J'ai un tas de fichiers vérous, sessions, log et divers qui ont plus
de 10 jours et qui ne sont pas obligatoirement à l'état ouvert, et
pourtant les applications qui les ont créé tournent toujours et par
expérience je sais qu'elles en ont encore besoin...
Il faut alors corriger ces applications pour qu'elles utilisent
/var/lock, /var/run et /var/log pour faire ceci. Avoir de l'espace
libre dans /tmp est crucial (un système peut être entièrement
immobilisé si les applis ne peuvent plus écrire de fichiers
temporaires) et il est donc très commun d'en effacer les vieux
fichiers. C'est d'ailleurs inscrit dans la norme POSIX ! Et rappelé
dans la FHS.
--
panic("bad_user_access_length executed (not cool, dude)");
2.0.38 /usr/src/linux/kernel/panic.c
OoO En cette matinée pluvieuse du mardi 10 août 2004, vers 10:58, "TiChou" disait:
J'ai un tas de fichiers vérous, sessions, log et divers qui ont plus de 10 jours et qui ne sont pas obligatoirement à l'état ouvert, et pourtant les applications qui les ont créé tournent toujours et par expérience je sais qu'elles en ont encore besoin...
Il faut alors corriger ces applications pour qu'elles utilisent /var/lock, /var/run et /var/log pour faire ceci. Avoir de l'espace libre dans /tmp est crucial (un système peut être entièrement immobilisé si les applis ne peuvent plus écrire de fichiers temporaires) et il est donc très commun d'en effacer les vieux fichiers. C'est d'ailleurs inscrit dans la norme POSIX ! Et rappelé dans la FHS. -- panic("bad_user_access_length executed (not cool, dude)"); 2.0.38 /usr/src/linux/kernel/panic.c
Jérémy JUST
On Tue, 10 Aug 2004 02:29:52 +0200 "TiChou" wrote:
Et par défaut, les fichiers non *accédés* depuis 10 jours sont supprimés (je viens de le vérifier à mes dépends), et ça se modifie dans /etc/cron.daily/tmpwatch
Ce qui est vraiment n'importe quoi !
Je ne vais pas répéter ce qu'on dit Nicolas George et Vincent Bernat, avec lesquels je suis assez d'accord.
Le nettoyage de /tmp est une tâche vitale. Si un serveur devait tourner pendant quelques années sans ménage avec des utilisateurs qui mettent leurs fichiers temporaires dans /tmp et qui les oublient, il faudrait une partition 100 ou 1000 fois plus grande que l'ensemble des autres volumes! D'autant plus que sur certains systèmes (Solaris), /tmp et le swap sont confondus. Donc /tmp plein => plus de swap => crash.
Le choix du atime m'a semblé judicieux, justement parce qu'il respecte les fichiers en cours d'utilisation (par un calcul, par exemple). Et les verrous, les fichiers de PID et les sockets sont bien mieux à leur place, dans /var/*/ Et puis, bon, si le choix de Mdk ne plaît pas, c'est l'affaire d'une minute de le changer (et encore moins pour supprimer le cron qui balaye).
-- Jérémy JUST
On Tue, 10 Aug 2004 02:29:52 +0200
"TiChou" <gro.uohcit@uohcit> wrote:
Et par défaut, les fichiers non *accédés* depuis 10 jours sont
supprimés (je viens de le vérifier à mes dépends), et ça se modifie
dans /etc/cron.daily/tmpwatch
Ce qui est vraiment n'importe quoi !
Je ne vais pas répéter ce qu'on dit Nicolas George et Vincent Bernat,
avec lesquels je suis assez d'accord.
Le nettoyage de /tmp est une tâche vitale.
Si un serveur devait tourner pendant quelques années sans ménage avec
des utilisateurs qui mettent leurs fichiers temporaires dans /tmp et qui
les oublient, il faudrait une partition 100 ou 1000 fois plus grande que
l'ensemble des autres volumes!
D'autant plus que sur certains systèmes (Solaris), /tmp et le swap
sont confondus. Donc /tmp plein => plus de swap => crash.
Le choix du atime m'a semblé judicieux, justement parce qu'il respecte
les fichiers en cours d'utilisation (par un calcul, par exemple). Et les
verrous, les fichiers de PID et les sockets sont bien mieux à leur
place, dans /var/*/
Et puis, bon, si le choix de Mdk ne plaît pas, c'est l'affaire d'une
minute de le changer (et encore moins pour supprimer le cron qui
balaye).
On Tue, 10 Aug 2004 02:29:52 +0200 "TiChou" wrote:
Et par défaut, les fichiers non *accédés* depuis 10 jours sont supprimés (je viens de le vérifier à mes dépends), et ça se modifie dans /etc/cron.daily/tmpwatch
Ce qui est vraiment n'importe quoi !
Je ne vais pas répéter ce qu'on dit Nicolas George et Vincent Bernat, avec lesquels je suis assez d'accord.
Le nettoyage de /tmp est une tâche vitale. Si un serveur devait tourner pendant quelques années sans ménage avec des utilisateurs qui mettent leurs fichiers temporaires dans /tmp et qui les oublient, il faudrait une partition 100 ou 1000 fois plus grande que l'ensemble des autres volumes! D'autant plus que sur certains systèmes (Solaris), /tmp et le swap sont confondus. Donc /tmp plein => plus de swap => crash.
Le choix du atime m'a semblé judicieux, justement parce qu'il respecte les fichiers en cours d'utilisation (par un calcul, par exemple). Et les verrous, les fichiers de PID et les sockets sont bien mieux à leur place, dans /var/*/ Et puis, bon, si le choix de Mdk ne plaît pas, c'est l'affaire d'une minute de le changer (et encore moins pour supprimer le cron qui balaye).
