Je d=E9bute dans l'administration de serveur freebsd et j'ai un soucis
dont je ne comprends pas la cause.
Je fait un df et je vois que ma partition /var est utilis=E9 =E0 87% (7,8
Go).
Je débute dans l'administration de serveur freebsd et j'ai un soucis dont je ne comprends pas la cause. Je fait un df et je vois que ma partition /var est utilisé à 87% (7,8 Go).
Tu debutes dans l'admin unix, en fait. c'est un enorme classique.
/dev/da0s1e 9.7G 7.8G 1.2G 87% /var
Et quand je veux trouver ce qui occupe de la place, je fais un du de la partition var: du /var Et là ce la m'affiche 355Mo.
Donc je n'arrive pas à trouver les fichiers/répertoires qui occupent de la place.
Lorsque tu ouvres un fichier a partir d'un process, ca te donne un file descriptor qui te permet d'acceder au fichier. Le systeme ne regarde plus du tout du tout quoi que ce soit cote nom de fichier ensuite.
Tu peux tres bien avoir sur ton disque des fichiers: - qui sont ouverts par un processus (par exemple, le fichier de log d'un daemon quelconque, assez souvent apache), et qui donc existent et prennent de la place, comme visible dans df. - qui n'ont plus de nom dans le filesystem, et qui donc apparaitront dans du.
C'est ce qui se passe si, par exemple, tu vois un fichier qui bouffe des mega que tu supprimes avec rm, sans te preoccuper de savoir ce qui genere le fichier en question.
Si c'est pas une erreur manuelle, ca sera par exemple un bug dans tes crontab de deplacement de fichiers de log, qui a oublie de prevenir les daemons correspondants.
Traditionnellement, les programmes serveurs sont concus par rapport a cette fonctionnalite. Le signal HUP, qui d'habitude sert a dire qu'un programme n'a plus de terminal de controle, est pre-empte pour les daemons (qui n'ont plus de terminaux de controle): un daemon bien ecrit va reagir a HUP en: - relisant ses fichiers de config, - reouvrant tous ses fichiers de log.
Meme si on peut douter du fait qu'apache soit bien ecrit, il reagit correctement a HUP.
Donc, regarde ce que tu as qui traine comme daemons, apache en tete, balance-leur un HUP, attend quelques secondes et tu vas sans doute recuperer ta place.
Si tu ne t'en sors pas comme ca, il existe des programmes (variant d'un unix a l'autre) qui peuvent te donner la liste des fichiers ouverts et des processus qui les tiennent. lsof, par exemple.
Pour reellement corriger ton souci, il faudra sans doute que tu determines si la place manquante provient d'une intervention manuelle, ou si c'est une crontab qui deconne.
C'est vraiment le BA-BA de l'admin. Je suppose que tu es auto-didacte dans l'admin Unix. Si tu as suivi une formation d'admin et qu'on ne t'a pas appris ca, celle-ci ne vaut rien. Si tu as lu un bouquin ou un site web, remplace-les par des choses un peu mieux foutues...
In article <6be5fb75-3fd4-43f5-a7e4-050f59b87c09@h2g2000yqj.googlegroups.com>,
Yan <yc@siweb.fr> wrote:
Je débute dans l'administration de serveur freebsd et j'ai un soucis
dont je ne comprends pas la cause.
Je fait un df et je vois que ma partition /var est utilisé à 87% (7,8
Go).
Tu debutes dans l'admin unix, en fait. c'est un enorme classique.
/dev/da0s1e 9.7G 7.8G 1.2G 87% /var
Et quand je veux trouver ce qui occupe de la place, je fais un du de
la partition var: du /var
Et là ce la m'affiche 355Mo.
Donc je n'arrive pas à trouver les fichiers/répertoires qui occupent
de la place.
Lorsque tu ouvres un fichier a partir d'un process, ca te donne un file
descriptor qui te permet d'acceder au fichier. Le systeme ne regarde plus
du tout du tout quoi que ce soit cote nom de fichier ensuite.
Tu peux tres bien avoir sur ton disque des fichiers:
- qui sont ouverts par un processus (par exemple, le fichier de log d'un
daemon quelconque, assez souvent apache), et qui donc existent et prennent
de la place, comme visible dans df.
- qui n'ont plus de nom dans le filesystem, et qui donc apparaitront dans du.
C'est ce qui se passe si, par exemple, tu vois un fichier qui bouffe des mega
que tu supprimes avec rm, sans te preoccuper de savoir ce qui genere le
fichier en question.
Si c'est pas une erreur manuelle, ca sera par exemple un bug dans tes
crontab de deplacement de fichiers de log, qui a oublie de prevenir les
daemons correspondants.
Traditionnellement, les programmes serveurs sont concus par rapport a cette
fonctionnalite. Le signal HUP, qui d'habitude sert a dire qu'un programme
n'a plus de terminal de controle, est pre-empte pour les daemons (qui n'ont
plus de terminaux de controle): un daemon bien ecrit va reagir a HUP en:
- relisant ses fichiers de config,
- reouvrant tous ses fichiers de log.
Meme si on peut douter du fait qu'apache soit bien ecrit, il reagit
correctement a HUP.
Donc, regarde ce que tu as qui traine comme daemons, apache en tete,
balance-leur un HUP, attend quelques secondes et tu vas sans doute recuperer
ta place.
Si tu ne t'en sors pas comme ca, il existe des programmes (variant d'un unix
a l'autre) qui peuvent te donner la liste des fichiers ouverts et des
processus qui les tiennent. lsof, par exemple.
Pour reellement corriger ton souci, il faudra sans doute que tu determines si
la place manquante provient d'une intervention manuelle, ou si c'est une
crontab qui deconne.
C'est vraiment le BA-BA de l'admin. Je suppose que tu es auto-didacte dans
l'admin Unix. Si tu as suivi une formation d'admin et qu'on ne t'a pas appris
ca, celle-ci ne vaut rien. Si tu as lu un bouquin ou un site web, remplace-les
par des choses un peu mieux foutues...
Je débute dans l'administration de serveur freebsd et j'ai un soucis dont je ne comprends pas la cause. Je fait un df et je vois que ma partition /var est utilisé à 87% (7,8 Go).
Tu debutes dans l'admin unix, en fait. c'est un enorme classique.
/dev/da0s1e 9.7G 7.8G 1.2G 87% /var
Et quand je veux trouver ce qui occupe de la place, je fais un du de la partition var: du /var Et là ce la m'affiche 355Mo.
Donc je n'arrive pas à trouver les fichiers/répertoires qui occupent de la place.
Lorsque tu ouvres un fichier a partir d'un process, ca te donne un file descriptor qui te permet d'acceder au fichier. Le systeme ne regarde plus du tout du tout quoi que ce soit cote nom de fichier ensuite.
Tu peux tres bien avoir sur ton disque des fichiers: - qui sont ouverts par un processus (par exemple, le fichier de log d'un daemon quelconque, assez souvent apache), et qui donc existent et prennent de la place, comme visible dans df. - qui n'ont plus de nom dans le filesystem, et qui donc apparaitront dans du.
C'est ce qui se passe si, par exemple, tu vois un fichier qui bouffe des mega que tu supprimes avec rm, sans te preoccuper de savoir ce qui genere le fichier en question.
Si c'est pas une erreur manuelle, ca sera par exemple un bug dans tes crontab de deplacement de fichiers de log, qui a oublie de prevenir les daemons correspondants.
Traditionnellement, les programmes serveurs sont concus par rapport a cette fonctionnalite. Le signal HUP, qui d'habitude sert a dire qu'un programme n'a plus de terminal de controle, est pre-empte pour les daemons (qui n'ont plus de terminaux de controle): un daemon bien ecrit va reagir a HUP en: - relisant ses fichiers de config, - reouvrant tous ses fichiers de log.
Meme si on peut douter du fait qu'apache soit bien ecrit, il reagit correctement a HUP.
Donc, regarde ce que tu as qui traine comme daemons, apache en tete, balance-leur un HUP, attend quelques secondes et tu vas sans doute recuperer ta place.
Si tu ne t'en sors pas comme ca, il existe des programmes (variant d'un unix a l'autre) qui peuvent te donner la liste des fichiers ouverts et des processus qui les tiennent. lsof, par exemple.
Pour reellement corriger ton souci, il faudra sans doute que tu determines si la place manquante provient d'une intervention manuelle, ou si c'est une crontab qui deconne.
C'est vraiment le BA-BA de l'admin. Je suppose que tu es auto-didacte dans l'admin Unix. Si tu as suivi une formation d'admin et qu'on ne t'a pas appris ca, celle-ci ne vaut rien. Si tu as lu un bouquin ou un site web, remplace-les par des choses un peu mieux foutues...
kevin vanier
Marc Espie a écrit :
C'est vraiment le BA-BA de l'admin. Je suppose que tu es auto-didacte dans l'admin Unix. Si tu as suivi une formation d'admin et qu'on ne t'a pas appris ca, celle-ci ne vaut rien. Si tu as lu un bouquin ou un site web, remplace-les par des choses un peu mieux foutues...
comme ceci . http://minilien.com/?7sjFlxuHxF
Marc Espie a écrit :
C'est vraiment le BA-BA de l'admin. Je suppose que tu es auto-didacte dans
l'admin Unix. Si tu as suivi une formation d'admin et qu'on ne t'a pas appris
ca, celle-ci ne vaut rien. Si tu as lu un bouquin ou un site web, remplace-les
par des choses un peu mieux foutues...
C'est vraiment le BA-BA de l'admin. Je suppose que tu es auto-didacte dans l'admin Unix. Si tu as suivi une formation d'admin et qu'on ne t'a pas appris ca, celle-ci ne vaut rien. Si tu as lu un bouquin ou un site web, remplace-les par des choses un peu mieux foutues...
comme ceci . http://minilien.com/?7sjFlxuHxF
yan
On 6 fév, 10:48, (Marc Espie) wrote:
In article com>,Yan wrote: >Je débute dans l'administration de serveur freebsd et j'ai un soucis >dont je ne comprends pas la cause. >Je fait un df et je vois que ma partition /var est utilisé à 87% (7, 8 >Go).
Tu debutes dans l'admin unix, en fait. c'est un enorme classique.
>/dev/da0s1e 9.7G 7.8G 1.2G 87% /var
>Et quand je veux trouver ce qui occupe de la place, je fais un du de >la partition var: du /var >Et là ce la m'affiche 355Mo.
>Donc je n'arrive pas à trouver les fichiers/répertoires qui occupent >de la place.
Lorsque tu ouvres un fichier a partir d'un process, ca te donne un file descriptor qui te permet d'acceder au fichier. Le systeme ne regarde p lus du tout du tout quoi que ce soit cote nom de fichier ensuite.
Tu peux tres bien avoir sur ton disque des fichiers: - qui sont ouverts par un processus (par exemple, le fichier de log d'un daemon quelconque, assez souvent apache), et qui donc existent et prennen t de la place, comme visible dans df. - qui n'ont plus de nom dans le filesystem, et qui donc apparaitront dans du.
C'est ce qui se passe si, par exemple, tu vois un fichier qui bouffe des mega que tu supprimes avec rm, sans te preoccuper de savoir ce qui genere le fichier en question.
Si c'est pas une erreur manuelle, ca sera par exemple un bug dans tes crontab de deplacement de fichiers de log, qui a oublie de prevenir les daemons correspondants.
Traditionnellement, les programmes serveurs sont concus par rapport a cet te fonctionnalite. Le signal HUP, qui d'habitude sert a dire qu'un programme n'a plus de terminal de controle, est pre-empte pour les daemons (qui n'o nt plus de terminaux de controle): un daemon bien ecrit va reagir a HUP en: - relisant ses fichiers de config, - reouvrant tous ses fichiers de log.
Meme si on peut douter du fait qu'apache soit bien ecrit, il reagit correctement a HUP.
Donc, regarde ce que tu as qui traine comme daemons, apache en tete, balance-leur un HUP, attend quelques secondes et tu vas sans doute recupe rer ta place.
Si tu ne t'en sors pas comme ca, il existe des programmes (variant d'un u nix a l'autre) qui peuvent te donner la liste des fichiers ouverts et des processus qui les tiennent. lsof, par exemple.
Pour reellement corriger ton souci, il faudra sans doute que tu determine s si la place manquante provient d'une intervention manuelle, ou si c'est une crontab qui deconne.
C'est vraiment le BA-BA de l'admin. Je suppose que tu es auto-didacte dan s l'admin Unix. Si tu as suivi une formation d'admin et qu'on ne t'a pas ap pris ca, celle-ci ne vaut rien. Si tu as lu un bouquin ou un site web, remplac e-les par des choses un peu mieux foutues...
Merci pour vos réponses.
Si je comprends bien je dois faire: "kill -HUP httpd" ?
Mais j'ai beaucoup de process httpd dans ma liste. Je dois le faire sur tous ?
Ciao.
On 6 fév, 10:48, es...@lain.home (Marc Espie) wrote:
In article <6be5fb75-3fd4-43f5-a7e4-050f59b87...@h2g2000yqj.googlegroups. com>,Yan <y...@siweb.fr> wrote:
>Je débute dans l'administration de serveur freebsd et j'ai un soucis
>dont je ne comprends pas la cause.
>Je fait un df et je vois que ma partition /var est utilisé à 87% (7, 8
>Go).
Tu debutes dans l'admin unix, en fait. c'est un enorme classique.
>/dev/da0s1e 9.7G 7.8G 1.2G 87% /var
>Et quand je veux trouver ce qui occupe de la place, je fais un du de
>la partition var: du /var
>Et là ce la m'affiche 355Mo.
>Donc je n'arrive pas à trouver les fichiers/répertoires qui occupent
>de la place.
Lorsque tu ouvres un fichier a partir d'un process, ca te donne un file
descriptor qui te permet d'acceder au fichier. Le systeme ne regarde p lus
du tout du tout quoi que ce soit cote nom de fichier ensuite.
Tu peux tres bien avoir sur ton disque des fichiers:
- qui sont ouverts par un processus (par exemple, le fichier de log d'un
daemon quelconque, assez souvent apache), et qui donc existent et prennen t
de la place, comme visible dans df.
- qui n'ont plus de nom dans le filesystem, et qui donc apparaitront dans du.
C'est ce qui se passe si, par exemple, tu vois un fichier qui bouffe des mega
que tu supprimes avec rm, sans te preoccuper de savoir ce qui genere le
fichier en question.
Si c'est pas une erreur manuelle, ca sera par exemple un bug dans tes
crontab de deplacement de fichiers de log, qui a oublie de prevenir les
daemons correspondants.
Traditionnellement, les programmes serveurs sont concus par rapport a cet te
fonctionnalite. Le signal HUP, qui d'habitude sert a dire qu'un programme
n'a plus de terminal de controle, est pre-empte pour les daemons (qui n'o nt
plus de terminaux de controle): un daemon bien ecrit va reagir a HUP en:
- relisant ses fichiers de config,
- reouvrant tous ses fichiers de log.
Meme si on peut douter du fait qu'apache soit bien ecrit, il reagit
correctement a HUP.
Donc, regarde ce que tu as qui traine comme daemons, apache en tete,
balance-leur un HUP, attend quelques secondes et tu vas sans doute recupe rer
ta place.
Si tu ne t'en sors pas comme ca, il existe des programmes (variant d'un u nix
a l'autre) qui peuvent te donner la liste des fichiers ouverts et des
processus qui les tiennent. lsof, par exemple.
Pour reellement corriger ton souci, il faudra sans doute que tu determine s si
la place manquante provient d'une intervention manuelle, ou si c'est une
crontab qui deconne.
C'est vraiment le BA-BA de l'admin. Je suppose que tu es auto-didacte dan s
l'admin Unix. Si tu as suivi une formation d'admin et qu'on ne t'a pas ap pris
ca, celle-ci ne vaut rien. Si tu as lu un bouquin ou un site web, remplac e-les
par des choses un peu mieux foutues...
Merci pour vos réponses.
Si je comprends bien je dois faire: "kill -HUP httpd" ?
Mais j'ai beaucoup de process httpd dans ma liste.
Je dois le faire sur tous ?
In article com>,Yan wrote: >Je débute dans l'administration de serveur freebsd et j'ai un soucis >dont je ne comprends pas la cause. >Je fait un df et je vois que ma partition /var est utilisé à 87% (7, 8 >Go).
Tu debutes dans l'admin unix, en fait. c'est un enorme classique.
>/dev/da0s1e 9.7G 7.8G 1.2G 87% /var
>Et quand je veux trouver ce qui occupe de la place, je fais un du de >la partition var: du /var >Et là ce la m'affiche 355Mo.
>Donc je n'arrive pas à trouver les fichiers/répertoires qui occupent >de la place.
Lorsque tu ouvres un fichier a partir d'un process, ca te donne un file descriptor qui te permet d'acceder au fichier. Le systeme ne regarde p lus du tout du tout quoi que ce soit cote nom de fichier ensuite.
Tu peux tres bien avoir sur ton disque des fichiers: - qui sont ouverts par un processus (par exemple, le fichier de log d'un daemon quelconque, assez souvent apache), et qui donc existent et prennen t de la place, comme visible dans df. - qui n'ont plus de nom dans le filesystem, et qui donc apparaitront dans du.
C'est ce qui se passe si, par exemple, tu vois un fichier qui bouffe des mega que tu supprimes avec rm, sans te preoccuper de savoir ce qui genere le fichier en question.
Si c'est pas une erreur manuelle, ca sera par exemple un bug dans tes crontab de deplacement de fichiers de log, qui a oublie de prevenir les daemons correspondants.
Traditionnellement, les programmes serveurs sont concus par rapport a cet te fonctionnalite. Le signal HUP, qui d'habitude sert a dire qu'un programme n'a plus de terminal de controle, est pre-empte pour les daemons (qui n'o nt plus de terminaux de controle): un daemon bien ecrit va reagir a HUP en: - relisant ses fichiers de config, - reouvrant tous ses fichiers de log.
Meme si on peut douter du fait qu'apache soit bien ecrit, il reagit correctement a HUP.
Donc, regarde ce que tu as qui traine comme daemons, apache en tete, balance-leur un HUP, attend quelques secondes et tu vas sans doute recupe rer ta place.
Si tu ne t'en sors pas comme ca, il existe des programmes (variant d'un u nix a l'autre) qui peuvent te donner la liste des fichiers ouverts et des processus qui les tiennent. lsof, par exemple.
Pour reellement corriger ton souci, il faudra sans doute que tu determine s si la place manquante provient d'une intervention manuelle, ou si c'est une crontab qui deconne.
C'est vraiment le BA-BA de l'admin. Je suppose que tu es auto-didacte dan s l'admin Unix. Si tu as suivi une formation d'admin et qu'on ne t'a pas ap pris ca, celle-ci ne vaut rien. Si tu as lu un bouquin ou un site web, remplac e-les par des choses un peu mieux foutues...
Merci pour vos réponses.
Si je comprends bien je dois faire: "kill -HUP httpd" ?
Mais j'ai beaucoup de process httpd dans ma liste. Je dois le faire sur tous ?
Ciao.
espie
In article , yan wrote:
Merci pour vos réponses.
Si je comprends bien je dois faire: "kill -HUP httpd" ?
Mais j'ai beaucoup de process httpd dans ma liste. Je dois le faire sur tous ?
Non, sur l'ancetre des autres, qui a de bonnes chances d'appartenir a root...
(note: si ma reponse etait un peu longue, c'est parce que tu ne t'en sortiras pas avec une "recette". Il faut vraiment que tu comprennes ce qui se passe. Il est *vraisemblable* que c'est apache qui tient tes fichiers en otage, mais ca peut etre un autre daemon).
In article <f2f9db35-ef7a-416b-b161-3fad86c2a3d3@c4g2000yqa.googlegroups.com>,
yan <y.chesneau@gmail.com> wrote:
Merci pour vos réponses.
Si je comprends bien je dois faire: "kill -HUP httpd" ?
Mais j'ai beaucoup de process httpd dans ma liste.
Je dois le faire sur tous ?
Non, sur l'ancetre des autres, qui a de bonnes chances d'appartenir a root...
(note: si ma reponse etait un peu longue, c'est parce que tu ne t'en
sortiras pas avec une "recette". Il faut vraiment que tu comprennes ce
qui se passe. Il est *vraisemblable* que c'est apache qui tient tes
fichiers en otage, mais ca peut etre un autre daemon).
Si je comprends bien je dois faire: "kill -HUP httpd" ?
Mais j'ai beaucoup de process httpd dans ma liste. Je dois le faire sur tous ?
Non, sur l'ancetre des autres, qui a de bonnes chances d'appartenir a root...
(note: si ma reponse etait un peu longue, c'est parce que tu ne t'en sortiras pas avec une "recette". Il faut vraiment que tu comprennes ce qui se passe. Il est *vraisemblable* que c'est apache qui tient tes fichiers en otage, mais ca peut etre un autre daemon).
yan
On 7 fév, 17:25, (Marc Espie) wrote:
In article com>,
yan wrote: >Merci pour vos réponses.
>Si je comprends bien je dois faire: "kill -HUP httpd" ?
>Mais j'ai beaucoup de process httpd dans ma liste. >Je dois le faire sur tous ?
Non, sur l'ancetre des autres, qui a de bonnes chances d'appartenir a roo t...
(note: si ma reponse etait un peu longue, c'est parce que tu ne t'en sortiras pas avec une "recette". Il faut vraiment que tu comprennes ce qui se passe. Il est *vraisemblable* que c'est apache qui tient tes fichiers en otage, mais ca peut etre un autre daemon).
Oui oui, je comprends très bien.
J'ai essayé de killer apache mais rien ne changeait.
Comme ca commençait à urger, j'ai redémarré le serveur et là j'ai récupéré tout mon espace.
Merci pour votre aide.
On 7 fév, 17:25, es...@lain.home (Marc Espie) wrote:
In article <f2f9db35-ef7a-416b-b161-3fad86c2a...@c4g2000yqa.googlegroups. com>,
yan <y.chesn...@gmail.com> wrote:
>Merci pour vos réponses.
>Si je comprends bien je dois faire: "kill -HUP httpd" ?
>Mais j'ai beaucoup de process httpd dans ma liste.
>Je dois le faire sur tous ?
Non, sur l'ancetre des autres, qui a de bonnes chances d'appartenir a roo t...
(note: si ma reponse etait un peu longue, c'est parce que tu ne t'en
sortiras pas avec une "recette". Il faut vraiment que tu comprennes ce
qui se passe. Il est *vraisemblable* que c'est apache qui tient tes
fichiers en otage, mais ca peut etre un autre daemon).
Oui oui, je comprends très bien.
J'ai essayé de killer apache mais rien ne changeait.
Comme ca commençait à urger, j'ai redémarré le serveur et là j'ai
récupéré tout mon espace.
>Si je comprends bien je dois faire: "kill -HUP httpd" ?
>Mais j'ai beaucoup de process httpd dans ma liste. >Je dois le faire sur tous ?
Non, sur l'ancetre des autres, qui a de bonnes chances d'appartenir a roo t...
(note: si ma reponse etait un peu longue, c'est parce que tu ne t'en sortiras pas avec une "recette". Il faut vraiment que tu comprennes ce qui se passe. Il est *vraisemblable* que c'est apache qui tient tes fichiers en otage, mais ca peut etre un autre daemon).
Oui oui, je comprends très bien.
J'ai essayé de killer apache mais rien ne changeait.
Comme ca commençait à urger, j'ai redémarré le serveur et là j'ai récupéré tout mon espace.
Merci pour votre aide.
xavier
yan wrote:
Si je comprends bien je dois faire: "kill -HUP httpd" ?
Hum... Il y a dans FreeBSD des mécanismes pour faire ça proprement :
sudo /usr/local/etc/rc.d/apache stop
-- XAv Disponible au 01/06/2010 <http://www.xavierhumbert.net/perso/CV2.html>
yan <y.chesneau@gmail.com> wrote:
Si je comprends bien je dois faire: "kill -HUP httpd" ?
Hum... Il y a dans FreeBSD des mécanismes pour faire ça proprement :
sudo /usr/local/etc/rc.d/apache stop
--
XAv
Disponible au 01/06/2010
<http://www.xavierhumbert.net/perso/CV2.html>
Alors dans ce cas, un "apachectl reload" fera l'affaire
-- XAv Disponible au 01/06/2010 <http://www.xavierhumbert.net/perso/CV2.html>
espie
In article <1jdkjxa.sbqgadjrtnb4N%, Xavier wrote:
Vivien MOREAU <vpm+ wrote:
C'est pas kill httpd, c'est kill -HUP httpd.
Alors dans ce cas, un "apachectl reload" fera l'affaire
ce qui au final, fait la meme chose. C'est bien qu'apache & co aient invente des trucs a eux plus ou moins standard pour ce genre de chose, mais le coup du -HUP sur les daemons, ca predate le apachectl reload de quelques annees, et ca le bon gout de marcher tres souvent meme lorsque tu n'as pas de foo reload (voire meme sur certains os ou la qualite des scripts de lancement/arret de daemons laisse franchement a desirer...)
In article <1jdkjxa.sbqgadjrtnb4N%xavier@groumpf.org>,
Xavier <xavier@groumpf.org> wrote:
Vivien MOREAU <vpm+news@serengetty.fr> wrote:
C'est pas kill httpd, c'est kill -HUP httpd.
Alors dans ce cas, un "apachectl reload" fera l'affaire
ce qui au final, fait la meme chose.
C'est bien qu'apache & co aient invente des trucs a eux plus ou moins
standard pour ce genre de chose, mais le coup du -HUP sur les daemons,
ca predate le apachectl reload de quelques annees, et ca le bon gout
de marcher tres souvent meme lorsque tu n'as pas de foo reload (voire
meme sur certains os ou la qualite des scripts de lancement/arret de
daemons laisse franchement a desirer...)
Alors dans ce cas, un "apachectl reload" fera l'affaire
ce qui au final, fait la meme chose. C'est bien qu'apache & co aient invente des trucs a eux plus ou moins standard pour ce genre de chose, mais le coup du -HUP sur les daemons, ca predate le apachectl reload de quelques annees, et ca le bon gout de marcher tres souvent meme lorsque tu n'as pas de foo reload (voire meme sur certains os ou la qualite des scripts de lancement/arret de daemons laisse franchement a desirer...)
xavier
Marc Espie wrote:
ce qui au final, fait la meme chose.
On est d'accord
C'est bien qu'apache & co aient invente des trucs a eux plus ou moins standard pour ce genre de chose, mais le coup du -HUP sur les daemons,
Dans ce cas, j'airaus tendance à préférer, sur les OS où ça existe `killall -HUP httpd`
ca predate le apachectl reload de quelques annees, et ca le bon gout de marcher tres souvent meme lorsque tu n'as pas de foo reload (voire meme sur certains os ou la qualite des scripts de lancement/arret de daemons laisse franchement a desirer...)
Des noms ? :-)
-- Xav Disponible au 01/04/2010 <http://www.xavierhumbert.net/perso/CV2.html>
Marc Espie <espie@lain.home> wrote:
ce qui au final, fait la meme chose.
On est d'accord
C'est bien qu'apache & co aient invente des trucs a eux plus ou moins
standard pour ce genre de chose, mais le coup du -HUP sur les daemons,
Dans ce cas, j'airaus tendance à préférer, sur les OS où ça existe
`killall -HUP httpd`
ca predate le apachectl reload de quelques annees, et ca le bon gout
de marcher tres souvent meme lorsque tu n'as pas de foo reload (voire
meme sur certains os ou la qualite des scripts de lancement/arret de
daemons laisse franchement a desirer...)
Des noms ? :-)
--
Xav
Disponible au 01/04/2010
<http://www.xavierhumbert.net/perso/CV2.html>
C'est bien qu'apache & co aient invente des trucs a eux plus ou moins standard pour ce genre de chose, mais le coup du -HUP sur les daemons,
Dans ce cas, j'airaus tendance à préférer, sur les OS où ça existe `killall -HUP httpd`
ca predate le apachectl reload de quelques annees, et ca le bon gout de marcher tres souvent meme lorsque tu n'as pas de foo reload (voire meme sur certains os ou la qualite des scripts de lancement/arret de daemons laisse franchement a desirer...)
Des noms ? :-)
-- Xav Disponible au 01/04/2010 <http://www.xavierhumbert.net/perso/CV2.html>
