J’ai un serveur dédié Kimsufi OVH avec une Ubuntu Server 11.10 en 64 bits.
Principalement des petits sites en Drupal et WordPress, mais aucun site à fort trafic.
J’ai quelques problèmes réguliers.
Mes graphiques de stat Munin sont « hachés », càd que, parfois, le plugin de stat Munin n’arrive pas à faire son calcul de statistique.
J’ai cherché, et surprise, parfois le serveur a des problèmes d’allocation mémoire ! 
J’ai ces problèmes sur certaines commandes, même parfois sur un « bête » « rm »
ou dans des scripts de mises à jour, j’obtiens :
sh: fork: Cannot allocate memory
Quand je relance la commande, elle passe (ce n’est pas à chaque fois).
Je vois aussi des erreurs dans les logs :
syslog :
Mar 4 04:11:11 ks380111 postfix/master[4654]: warning: master_spawn: fork: Cannot allocate memory -- throttling idem dans les logs Apache : [Sun Mar 04 10:39:13 2012] [error] (12)Cannot allocate memory: fork: Unable to fork new process
et effectivement, je trouve un mail dans /var/mail/root : Munin a ce problème de temps en temps
fork failed: Cannot allocate memory at /usr/share/perl5/Munin/Master/GraphOld.pm line 614. /usr/bin/munin-cron: fork: Cannot allocate memory
Ce n’est donc pas propre à un programme précis.
Vous allez me dire : « Simple : pas assez de mémoire » ….
euh, oui…
Mais j’avais un serveur Kimsufi (gamme 2009) avec 4GB, et pas de problèmes…
Je suis passé sur un serveur Kimsufi (gamme 2011) avec 24 GB de mémoire et Core i7
et je n’ai pas assez de mémoire ? 
(j’ai réinstallé une version Ubuntu Server plus récente)
… franchement, c’est déroutant !
Donc, ok, c’est un problème de mémoire, mais POURQUOI ? avec 24 GB ?
(et Munin me dit qu’il reste toujours minimum 6 ou 700 MB de libre)
Le cpu est sous-utilisé (j’arrive entre 100 et 200% sur un Core i7, Quad core et Hyper-threading…)
Le nombre de process Apache reste très faible (5 à 10)
# free -m total used free shared buffers cached Mem: 24149 23440 708 0 820 19389 -/+ buffers/cache: 3230 20918 Swap: 12597 0 12597
Précision : je n’utilise pas de machine virtuelle.
C’est uniquement une Ubuntu Server 11.10 classique, en mémoire réelle.
Comprend pas 
On a un serveur de course, et on tombe à cours de mémoire ! 
…
J’analyse ça en détail et je fais quelques recherches sur le Net.
Je regarde les logs, et comme le manque de mémoire donne des problèmes lors de la création de « fork », je fais une recherche sur « fork ».
Surprise, je trouve maintenant d’autres messages parlant de « /bin/fuser » :
Mar 18 07:10:13 ks380111 kernel: grsec: failed fork with errno ENOMEM by /bin/fuser[fuser:3066] uid/euid:0/0 gid/egid:0/0, parent /usr/bin/find[find:7800] uid/euid:0/0 gid/egid:0/0 Mar 18 07:10:13 ks380111 kernel:
last message repeated 4 times
Mar 18 07:10:13 ks380111 kernel: grsec: more alerts, logging disabled for 10 seconds
Mar 18 07:10:26 ks380111 kernel: grsec: failed fork with errno ENOMEM by /bin/fuser[fuser:3066] uid/euid:0/0 gid/egid:0/0, parent /usr/bin/find[find:7800] uid/euid:0/0 gid/egid:0/0 Mar 18 07:10:26 ks380111 kernel:
last message repeated 4 times
Il y a énormément de messages d’erreur avec « fuser ».
Je fais une recherche sur ce message d’erreur.
Je trouve plusieurs références, d’abord sur ubuntuforums.org mais aussi sur le launchpad Ubuntu et même sur Debian !
Voici les liens intéressants :
- Fuser high CPU usage (ubuntuforums.org)
- fuser forking uncontrollably in cron job (ubuntuforums.org)
- fuser forking uncontrollably in cron job (launchpad)
- Debian Bug report logs – #633100 : php5-common: /etc/cron.d/php5 script runs find with fuser process which spawns too much process eats up the system
Le bug est connu. Il est apparu dans Ubuntu 11.10 et est présent dans Debian également.
Une tâche Cron exécutée toutes les 30 minutes, utilise « fuser ». Une modification introduite avec Ubuntu 11.10 fait que Fuser crée des tâches qui restent « zombies », et de ce fait, prennent très rapidement toutes les ressources du serveur.
J’essaye de vérifier cela sur mon serveur. Et j’arrive finalement à trouver des milliers de tâches « fuser ».
root@ks123456:/etc/cron.d# ps -C fuser | wc -l
29329
hum… presque 30.000 jobs « fuser » !!!
Je comprend que ça bouffe la mémoire et qu’on peut avoir plein de tâches qui ne peuvent plus obtenir de la mémoire.
Cela ne dure pas, probablement quelques dizaines de secondes, mais les tâches (ou vos visiteurs) qui doivent démarrer à ce moment n’obtiennent évidemment pas la mémoire voulue, et on obtient des erreurs « fork: Cannot allocate memory » !
Cette tâche cron se trouve dans /etc/cron.d/php5 .
Comment corriger ce problème ?
Il y a 2 solutions :
- soit remettre dans /etc/cron.d/php5 la ligne de commande qui existait jusqu’en Ubuntu 11.04
- soit corriger le bug qui se trouve en fait dans « psmisc »
Si vous choisissez de modifier le cron,suivez la solution de Graham Poulter en remplaçant la ligne de commande dans /etc/cron.d/php5 :
« My workaround is to restore the php5 cron job from 11.04, which does not call fuser:
This is the 11.10 cron job:
09,39 * * * * root [ -x /usr/lib/php5/maxlifetime ] && [ -d /var/lib/php5 ] && find /var/lib/php5/ -depth -mindepth 1 -maxdepth 1 -type f -cmin +$(/usr/lib/php5/maxlifetime) ! -execdir fuser -s {} 2>/dev/null \; -delete
And this is the 11.04 cron job:
09,39 * * * * root [ -x /usr/lib/php5/maxlifetime ] && [ -d /var/lib/php5 ] && find /var/lib/php5/ -depth -mindepth 1 -maxdepth 1 -type f -cmin +$(/usr/lib/php5/maxlifetime) -delete
We think fuser was added to cater for some edge case of process not closing the session file, but was never tested with a large number of sessions. »
Il vous suffit de remettre la ligne de commande qui existait en Ubuntu 11.04.
Je n’ai pas testé cette solution, mais plusieurs personnes confirment que cela résout effectivement le problème.
La 2ème solution est de corriger « psmisc ».
Plutôt que de modifier le code, j’ai préféré mettre à jour le système et passer à une version plus récente de PHP5.
Dans Ubuntu 11.10, on a PHP5 version5.3.6 et psmisc version 22.14 :
root@ks123456:/etc/cron.d# apt-cache policy psmisc
psmisc:
Installed: 22.14-1
Candidate: 22.14-1
Version table:
*** 22.14-1 0
Pour upgrader PHP5 et psmisc, on peut utiliser le dépôt ppa:ondrej/php5 d’ Ondřej Surý.
Attention, vous allez installer une version non officiellement supportée et suivie en Ubuntu 11.10 …
Il suffit d’ajouter ce dépôt avec la commande :
sudo add-apt-repository ppa:ondrej/php5
mais je remarque que sur mon serveur, cette commande n’est pas acceptée.
Vous pouvez alors ajouter manuellement le dépôt dans /etc/apt/sources.list.
Ajouter ces 2 lignes en fin de votre /etc/apt/sources.list :
deb http://ppa.launchpad.net/ondrej/php5/ubuntu oneiric main deb-src http://ppa.launchpad.net/ondrej/php5/ubuntu oneiric main
Sauvez, mais avant de faire la mise à jour, il vous fait ajouter la clé permettant d’authentifier le dépôt.
# sudo apt-key adv –keyserver keyserver.ubuntu.com –recv-keys E5267A6C
Executing: gpg –ignore-time-conflict –no-options –no-default-keyring –secret-keyring /tmp/tmp.WqqyD1UE94 –trustdb-name /etc/apt/trustdb.gpg –keyring /etc/apt/trusted.gpg –primary-keyring /etc/apt/trusted.gpg –keyserver keyserver.ubuntu.com –recv-keys E5267A6C
gpg: requesting key E5267A6C from hkp server keyserver.ubuntu.com
gpg: key E5267A6C: public key « Launchpad PPA for Ondřej Surý » imported
gpg: Total number processed: 1
gpg: imported: 1 (RSA: 1)
Faites maintenant la mise à jour :
# aptitude update
# aptitude dist-upgrade
The following NEW packages will be installed:
libonig2{a} libqdbm14{a}
The following packages will be REMOVED:
libt1-5{u}
The following packages will be upgraded:
libapache2-mod-php5 php-pear php5 php5-cli php5-common php5-curl php5-dev php5-gd php5-imap php5-intl php5-mcrypt php5-mysql
php5-pspell php5-recode php5-snmp php5-sqlite php5-tidy php5-xmlrpc php5-xsl psmisc
20 packages upgraded, 2 newly installed, 1 to remove and 0 not upgraded.
Need to get 7,377 kB of archives. After unpacking 602 kB will be used.
The following packages have unmet dependencies:
php5-ps: Depends: phpapi-20090626 which is a virtual package.
php5-imagick: Depends: phpapi-20090626 which is a virtual package.
php5-memcache: Depends: phpapi-20090626 which is a virtual package.
php5-ming: Depends: phpapi-20090626 which is a virtual package.
The following actions will resolve these dependencies:
Remove the following packages:
1) php5-imagick
2) php5-memcache
3) php5-ming
4) php5-ps
Accept this solution? [Y/n/q/?] q
Abandoning all efforts to resolve these dependencies.
Abort.
J’ai préférer ne pas faire la mise à jour de PHP5 et psmisc du fait de ces problèmes de dépendances. Ça attendra la sortie d’ Ubuntu 12.04 LTS.
Je suis revenu à la 1ère possibilité qui est l’édition de /etc/cron.d/php5.
J’ai remis la ligne de commande qui existait en Ubuntu 11.04.
C’est moins risqué sur un serveur de production, et en cas de besoin je peux facilement remettre la commande 11.10.
Je vais maintenant vérifier pendant 24h si je n’ai plus d’erreur de fork et de mémoire 
Après 12h de fonctionnement, cela semble positif :
J’ai modifié la ligne de commande dans /etc/cron.d/php5 vers 3h cette nuit.
On remarque que depuis 3h, il n’y a plus eu d’interruption dans les statistiques Munin.
De plus, le temps cpu utilisé par Munin est redevenu régulier.
La consommation CPU est aussi fortement descendue. Le serveur (Core i7, 24 GB de mémoire) est largement sous-utilisé. On a de la réserve.
Tout est normal. On peut dire que le problème est résolu
Bonsoir,
J’ai le même message d’erreur pour des commandes basique, mais il s’agit de VKS d’OVH qui n’ont que 512Mo de mémoire vive, j’ai du baisser la conf apache pour éviter de saturer la mémoire avec un serveur sans visiteur…
Mais depuis peu, OVH a mieux régler les machines virtuelle et je suis pas obliger de redémarrer ce petit VKS pour le dé-freezer.
En tous cas, je garde sous le coude ta péripétie, car elle peut encore servir dans les semaines qui viennent.
Bonne soirée.
19 mars 2012 at 23:21Nicolas.
Bonsoir Nicolas,
VKS ?
Ou VPS ?
Car VKS, je ne connais pas (mais je n’ai pas creusé les dernières offres virtuelles d’ OVH).
Effectivement, 512 MB, ce n’est pas énorme. Mais ça dépend de la charge de ton serveur.
Si tu as la main sur l’installation de l’ OS sur cette machine virtuelle, c’est une Ubuntu ? 11.10 ?
Si c’est le cas, tu peux faire la modif dans /etc/cron.d/php5.
Sinon, à suivre,à surveiller, et voir sur le forum OVH si d’autres ont le même problème que toi.
Bonne soirée
19 mars 2012 at 23:42Didier
Bonjour,
si la comment add-apt-repository ne marche pas, c’est qu’il faut installer le paquet python-software-properties
Merci beaucoup pour ça. Je suis tombé dessus par hasard, mais heureusement, comme ça j’ai installé directement la dernière version de php.
19 avril 2012 at 18:28Salut.
Je viens de tomber sur votre lien.
Moi aussi, j’ai eu ce souci que je viens de régler.
Par contre moi j’avais trouvé que c’était fuse qui consommait toutes les ressources. mais je ne comprenais pas ce qui le lançait.
même un pstree ne peux pas fonctionner du fait que les sous processus du cron meurent et de nouveaux se créent.
Bref, Mon problème moi survient tous les soirs à 22h sur mon serveur et comme je ne suis pas toujours devant mon pc je n’ai pas pu comprendre l’origine de ce maudit problème.
pour le régler j’ai commenté la ligne du fichier /etc/cron.d/php5
et encore une fois merci pour ce partage.
à très bientôt.
12 juin 2012 at 0:10–
Lotfi
Bonjour Lotfi,
Vraiment content que mes explications te soient utiles
Oui, j’ai eu difficile de trouver ce que c’était, car ça n’arrive que quelques secondes toutes les 30 minutes, et à ce moment là les commandes permettant de rechercher le coupable, plantent aussi en général …
Mais ok, c’est résolu, et en plus maintenant Ubuntu 12.04 est sorti (mais je n’ai pas encore fait la mise à jour).
Bon après-midi
12 juin 2012 at 13:49Didier
Merci Dominique pour cette précision.
Didier
12 juin 2012 at 13:51