Re: Crash et stratégie
On Fri, 7 Mar 2003 16:37:03 +0100
Frédéric Bothamy <fbothamy@mail.dotcom.fr> wrote:
> * François Boisson <user@maison.homelinux.net> [2003-03-07 15:54] :
> > Hier, la connexion Internet s'est coupé sur tout le lycée (dixit
> > l'administration). Constataion plus de serveur de nom, je relance le
> > bazar et je regarde les logs:
> >
> >
> > Mar 6 15:38:30 yoda kernel: VM: killing process named
> > Mar 6 15:41:34 yoda kernel: VM: killing process apache
>
> Quel noyau ? 2.2.x ou 2.4.x ?
2.2.19
>
> > Epluchage des logs pour voir d'où ça vient (il n'était pas 6h25 et pas
> > de cron particulier à cet heure là!): L'origine vient d'un Marseillais
> > (ou...
> > -> Pourquoi named et apache et pas d'autres processus?
>
> Parce qu'ils occupent beaucoup de place mémoire ? Et ils sont donc
> "intéressants" pour la VM du noyau car leur mort libérera de la place
> mémoire que le noyau pourra utiliser.
J'aurais pu y pensé, c'est logique.
>
> > -> Est ce à votre avis un comportement volontaire (qui n'a marché que
> > parce que le serveur n'est pas vraiment une grosse bécane) ou une
> > maladresse de personne hystérique sur sa souris? Je serais pour cette
>
> Il faudrait demander à la personne elle-même !
C'est sûr.
> Ça fait beaucoup tout
> de même pour une maladresse, je pencherais pour la première hypothèse.
>
L'argument est bon...
> > deuxième hypothèse, on n'aspire pas un site tout en essayant de le
> > flinguer...-> Y-aurait-il une faille de ce type dans phpBB2 (inflation
> > des ressources)? (Je ne pense pas, le forum commence à enfler et le
> > pbm est
>
> J'ai vaguement entendu dire que ce forum n'était pas un modèle du
> point de vue de la sécurité, mais ce n'est qu'un ouï-dire et il est
> difficile de demander aux utilisateurs de renoncer à un forum ou de
> basculer sur un autre sans bonne raison valable.
Le problème est que cela entraine la perte de tous les messages à moins
d'un procédé d'importation long si il est possible.
>
> > que 64M, c'est juste je pense)-> La machine avait bien récupérée et il
> > aurait suffit que named se relance tout seul. Script dans cron (me
> > parait une bonne idée mais la crontab devient chargée), entrée dans
> > inittab + respawn (il faut maitriser le sujet notamment le
> > comportement au boot d'une telle entrée)
>
> Sinon, il y a quelques programmes (paquet daemon de unstable par
> exemple) qui permettent de manager un programme comme si c'était un
> démon et qui peuvent le relancer s'il vient à être tué. Mais il ne
> faut pas que celui-ci soit tué. :-)
Ca aussi, c'est logique.
>
> Le "mieux" ici est effectivement d'ajouter de la mémoire, d'augmenter
> la partition de swap (ne pas hésiter à aller large : 400 Mo ne serait
> pas du luxe si la machine est censée être chargée) et essayer de
> limiter l'impact des connexions entrantes (ça, je ne sais pas trop
> comment faire ça simplement).
>
Dans l'urgence, j'ai fait les opérations suivantes:
yoda:~# cd /usr
yoda:/usr# df
Filesystem 1k-blocks Used Available Use% Mounted on
/dev/hda1 731694 229099 464797 33% /
/dev/hda3 1462974 647189 740185 47% /usr
/dev/sda1 9866233 7353108 2001126 79% /home
/dev/hda4 3821054 2972106 651254 82% /divers
/dev/sda2 7409941 5693399 1332491 81% /husr
/husr/sysftp 1014911 550037 412446 57% /ftp
yoda:/usr# dd if=/dev/zero of=SWAP.DSK bs=1024k count=300
300+0 enregistrements lus.
300+0 enregistrements écrits.
yoda:/usr# mkswap SWAP.DSK
Configuration de l'espace de swap version 1, taille = 314568704 octets
yoda:/usr# swapon SWAP.DSK
yoda:/usr#
yoda:/usr# cat /proc/meminfo
total: used: free: shared: buffers: cached:
Mem: 130686976 126803968 3883008 67080192 45547520 11157504
Swap: 391974912 0 391974912
MemTotal: 127624 kB
MemFree: 3792 kB
MemShared: 65508 kB
Buffers: 44480 kB
Cached: 10896 kB
SwapTotal: 382788 kB
SwapFree: 382788 kB
yoda:/usr#
C'est osé, mais y-a-t-il des raisons objectives valables pour un swap sur
un fichier (mis à part que c'est l'option de Microsoft ce qui est louche).
Le choix du répertoire /usr est qu'il n'y a pas de mouvements sur ce
disque et que lui prendre 300M n'est pas gênant pour le système. On arrive
à un total de 390M de swap ce qui n'est pas si mal.
François Boisson
Reply to: