> Le Fri, Mar 17, 2017 at 08:30:21AM +0100, Daniel Caillibaud a écrit : > > > > Tu peux installer atop sur le host, et le régler avec une mesure par minute > > (10 par défaut, > > dans /etc/default/atop mettre `INTERVAL=60`), ça devrait te permettre après > > coup de voir à > > chaque minute l'état complet du host, par ex atop -r > > /var/log/atop/atop_YYYYmmdd -b hh:mm > > pour avoir un top amélioré de cette minute là, que tu peux trier par conso > > RAM, CPU, disque, > > etc. (man atop pour les détails).
Le Mon, Sep 04, 2017 at 09:27:52AM +0900, Charles Plessy a écrit :> > > Nouveau plantage, mais cette fois-ci j'avais une fenêtre root ouverte. > Comme d'habitude, de nombreux processus « CRON -f » et impossibilité de > créer de nouvelles sessions (SSH, sudo, ...). Cause ou conséquence, > cette fois-ci un démon gitlab-ci-multi-runner (source: > https://packages.gitlab.com/runner) accumulait des dizaines d'instances > (car il plantait naturellement suite à une différence de compatibilité > avec notre serveur local). Je l'ai désinstallé, j'ai tué tous les > processus cron, j'ai relancé le service cron avec systemctl et j'ai > fini par un « systemctl reset-failed ». Je peux de nouveau me connecter > à la machine sans avoir eu besoin de la redémarrer. Bonjour à tous, nouveau plantage, toujours rien dans les logs ou atop. Cette fois-ci, la machine a re-planté (pas de nouvelles identifications possibles) peu après son redémarrage. Voici ce que je vois avec ssh -vvv: Tout va bien jusque: Authenticated to <la machine> ([<son IP>]:22). debug1: channel 0: new [client-session] debug3: ssh_session2_open: channel_new: 0 debug2: channel 0: send open debug3: send packet: type 90 debug1: Requesting [email protected] debug3: send packet: type 80 debug1: Entering interactive session. debug1: pledge: exec Ensuite, plus rien pendant longtemps, et ensuite, la machine casse son pipe. debug3: send packet: type 1 packet_write_wait: Connection to <son IP> port 22: Broken pipe Perplexe, Charles -- Charles Plessy Tsurumi, Kanagawa, Japon
