Logo GNT
Actualités Tests & Guides Bons Plans
Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11
Entraide Linux Autres OS Linux Debian Serveur bloqué par de multiples CRON -f ?

Serveur bloqué par de multiples CRON -f ?

7 réponses
Avatar
Charles Plessy
Bonjour à tous,

J'ai un serveur (en fait, une machine virtuelle) qui se bloque tous les deux ou
trois mois, de la manière suivante:

- Impossible de se connecter en SSH.
- Les connections en cours fonctionnent jusqu'à ce qu'on les tue ou les bloque.
- Impossible de prendre les droits administrateur avec sudo (bloque la session).
- Des processus « CRON -f » qui s'accumulent.
- Journal systemd qui ne contient plus rien à partir du début du bloquage.
- systlog et messages pas plus intéressants: un « -- MARK -- » toutes les 20
minutes et c'est tout.

Je ne sais pas si les processus CRON sont une cause ou un symptome...

Avez vous vu ça ailleurs ? Pour le moment je bloque et Duck Duck Go (avec et
sans !g) ne trouve rien non plus avec des mots-clés comme « "CRON -f" debian
blocked ».

Je vais devoir redémarrer le serveur demain matin, et je n'ai accès que depuis
l'ordinateur du bureau, donc avec le décalage horaire, je ne vais probablement
pouvoir répondre qu'à une seule série de questions si vous en avez.

Ceci dit, vos lumières sont les très bienvenues !

Charles

--
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan
Signaler un problème avec ce contenu

7 réponses

Supprimer
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
Avatar
randy11
Bonjour à tous,
J'ai un serveur (en fait, une machine virtuelle) qui se bloque tous les deu x ou
trois mois, de la manière suivante:
- Impossible de se connecter en SSH.
- Les connections en cours fonctionnent jusqu'à ce qu'on les tue ou l es bloque.
- Impossible de prendre les droits administrateur avec sudo (bloque la ses sion).
- Des processus « CRON -f » qui s'accumulent.
- Journal systemd qui ne contient plus rien à partir du début du bloquage.
- systlog et messages pas plus intéressants: un « -- MARK - - » toutes les 20
minutes et c'est tout.
Je ne sais pas si les processus CRON sont une cause ou un symptome...
Bonjour,
Quels sont les tâches confiées à la crontab ?
Toutes les actions "cron" sont-elles lancées par le même utilisat eurs ?
Cause classique de blocage, un problème réseau : est-ce qu'il y a
du NFS ? du LDAP ou NIS ? un automounter (autofs) ? du kerberos ?
Désolé, mais je n'ai que des questions.
Randy11
Avatar
Daniel Caillibaud
Le 29/11/16 à 17:59, Charles Plessy a écrit :
CP> - Impossible de se connecter en SSH.
Est-ce que auth.log dit qqchose lors de ces tentatives échouées ?
CP> - Les connections en cours fonctionnent jusqu'à ce qu'on les tue ou les bloque.
Et depuis une connexion qui marche, tu vois rien d'intéressant lorsque
CP> - Impossible de prendre les droits administrateur avec sudo (bloque la session).
Le message d'erreur permet pas de t'aiguiller ?
CP> - Des processus « CRON -f » qui s'accumulent.
Bizarre normalement y'en a qu'un(-f c'est foreground), tu sais qui les lanc e ?
(je pense à un truc de monitoring qui vérifierait que cron est la ncé, croit qu'il ne l'est pas
et le relance).
Tu sais si ces cron lancent d'autres choses (un ps avec f permet de le voir ) ?
CP> - Journal systemd qui ne contient plus rien à partir du débu t du bloquage.
CP> - systlog et messages pas plus intéressants: un « -- MA RK -- » toutes les 20
CP> minutes et c'est tout.
Ça dit déjà que le système peut écrire (le reste p ourrait laisser penser à un disque passé en
read only).
Pas vraiment d'idée, le kern.log ne dit rien ?
Si tu n'as pas de kern.log, tu peux installer rsyslog pour qu'il le crà ©e à partir des messages
de systemd, mais si t'as rien avec journalctl y'aura probablement rien de p lus.
CP> Je ne sais pas si les processus CRON sont une cause ou un symptome...
Si tu les kill (depuis une console ouverte avant qui continue de répon dre), ça donne qqchose ?
Tu peux laisser tourner un script qui check le nb de cron et t'envoie un ma il dès qu'il y en a
plus d'un, par ex
#!/bin/bash
sent=NO
while [ $sent == "NO" ]; do
[ $(ps ax|grep -c '[c]ron -f') -gt 1 ]
&& ps auxwf|mail -s "trop de cron"
&& sent=YES
sleep 10
done
Histoire de voir si tu peux te connecter juste après et que ça d égénère plus tard (au moins tu
auras tous les processus à ce moment là dans le mail, tu peux ajo uter d'autres infos au mail
envoyé).
--
Daniel
Mourir pour des idées, d'accord mais de mort lente.
Georges Brassens.
Avatar
Charles Plessy
Merci Daniel et randy11 pour vous réponses, et Joyeux Noël à tous !
Il y a du NFS, mais les systèmes de fichier sont accessibles.
NIS est installé. Je ne suis pas certain qu'il soit utilisé (comment le
vérifier ?).
Le Wed, Nov 30, 2016 at 11:09:57AM +0100, Daniel Caillibaud a écrit :
Le 29/11/16 à 17:59, Charles Plessy a écrit :
CP> - Impossible de se connecter en SSH.
Est-ce que auth.log dit qqchose lors de ces tentatives échouées ?

Rien... À partir du moment ou le problème commence, auth.log ne contient plus
aucune nouvelle ligne.
$ tail auth.log
Dec 19 13:17:01 dgt-med CRON[21322]: pam_unix(cron:session): session opened for user root by (uid=0)
Dec 19 13:17:01 dgt-med CRON[21322]: pam_unix(cron:session): session closed for user root
Dec 19 14:17:01 dgt-med CRON[2037]: pam_unix(cron:session): session opened for user root by (uid=0)
Dec 19 14:17:01 dgt-med CRON[2037]: pam_unix(cron:session): session closed for user root
Dec 19 15:17:01 dgt-med CRON[3979]: pam_unix(cron:session): session opened for user root by (uid=0)
Dec 19 15:17:01 dgt-med CRON[3979]: pam_unix(cron:session): session closed for user root
Dec 19 16:17:01 dgt-med CRON[5722]: pam_unix(cron:session): session opened for user root by (uid=0)
Dec 19 16:17:01 dgt-med CRON[5722]: pam_unix(cron:session): session closed for user root
Dec 19 17:17:01 dgt-med CRON[7597]: pam_unix(cron:session): session opened for user root by (uid=0)
Dec 19 17:17:01 dgt-med CRON[7597]: pam_unix(cron:session): session closed for user root
CP> - Les connections en cours fonctionnent jusqu'à ce qu'on les tue ou les bloque.
Et depuis une connexion qui marche, tu vois rien d'intéressant lorsque

Tout fonctionne parfaitement sauf que personne ne peut plus s'identifier.
CP> - Impossible de prendre les droits administrateur avec sudo (bloque la session).
Le message d'erreur permet pas de t'aiguiller ?

Pas de message. Une fois appuyé sur « entrée », le curseur passe à la ligne,
rien de nouveau ne s'affiche et la session ne rend pas la main.
CP> - Des processus « CRON -f » qui s'accumulent.
Bizarre normalement y'en a qu'un(-f c'est foreground), tu sais qui les lance ?

$ ps aux | grep CRON | tail
root 30652 0.0 0.0 57496 2860 ? S Dec22 0:00 /usr/sbin/CRON -f
root 30694 0.0 0.0 57496 2860 ? S Dec21 0:00 /usr/sbin/CRON -f
root 30793 0.0 0.0 57496 2860 ? S Dec23 0:00 /usr/sbin/CRON -f
root 30925 0.0 0.0 57496 2860 ? S Dec24 0:00 /usr/sbin/CRON -f
root 31091 0.0 0.0 57496 2860 ? S Dec25 0:00 /usr/sbin/CRON -f
root 31267 0.0 0.0 57496 2860 ? S Dec25 0:00 /usr/sbin/CRON -f
root 31661 0.0 0.0 57496 2860 ? S Dec20 0:00 /usr/sbin/CRON -f
root 32347 0.0 0.0 57496 2860 ? S Dec22 0:00 /usr/sbin/CRON -f
root 32488 0.0 0.0 57496 2860 ? S Dec23 0:00 /usr/sbin/CRON -f
root 32621 0.0 0.0 57496 2860 ? S Dec24 0:00 /usr/sbin/CRON -f
(je pense à un truc de monitoring qui vérifierait que cron est lancé, croit qu'il ne l'est pas
et le relance).
Tu sais si ces cron lancent d'autres choses (un ps avec f permet de le voir) ?

$ pstree 536
cron───176*[cron]
CP> - Journal systemd qui ne contient plus rien à partir du début du bloquage.
CP> - systlog et messages pas plus intéressants: un « -- MARK -- » toutes les 20
CP> minutes et c'est tout.
Ça dit déjà que le système peut écrire (le reste pourrait laisser penser à un disque passé en
read only).
Pas vraiment d'idée, le kern.log ne dit rien ?

Dernier segfault le Dec 15 02:08:53, 4 jours avant que les ennuis ne recommencent.
Si tu n'as pas de kern.log, tu peux installer rsyslog pour qu'il le crée à partir des messages
de systemd, mais si t'as rien avec journalctl y'aura probablement rien de plus.

$ journalctl -e | tail -n40
Dec 16 17:50:58 dgt-med systemd[24205]: Received SIGRTMIN+24 from PID 16150 (kill).
Dec 16 17:50:59 dgt-med systemd[1]: Stopped User Manager for UID XXXXX.
Dec 16 17:50:59 dgt-med systemd[1]: Stopping user-XXXXX.slice.
Dec 16 17:50:59 dgt-med systemd[1]: Removed slice user-XXXXX.slice.
Dec 17 13:51:22 dgt-med systemd[1]: Starting Cleanup of Temporary Directories...
Dec 17 13:51:22 dgt-med systemd[1]: Started Cleanup of Temporary Directories.
Dec 18 13:51:42 dgt-med systemd[1]: Starting Cleanup of Temporary Directories...
Dec 18 13:51:42 dgt-med systemd[1]: Started Cleanup of Temporary Directories.
Dec 19 11:56:50 dgt-med systemd[1]: Starting user-XXXXX.slice.
Dec 19 11:56:50 dgt-med systemd[1]: Created slice user-XXXXX.slice.
Dec 19 11:56:50 dgt-med systemd[1]: Starting User Manager for UID XXXXX...
Dec 19 11:56:50 dgt-med systemd[1]: Starting Session 783 of user XXXXXXXX.
Dec 19 11:56:50 dgt-med systemd-logind[628]: New session 783 of user XXXXXXXX.
Dec 19 11:56:50 dgt-med systemd[12156]: Starting Paths.
Dec 19 11:56:50 dgt-med systemd[12156]: Reached target Paths.
Dec 19 11:56:50 dgt-med systemd[12156]: Starting Timers.
Dec 19 11:56:50 dgt-med systemd[12156]: Reached target Timers.
Dec 19 11:56:50 dgt-med systemd[12156]: Starting Sockets.
Dec 19 11:56:50 dgt-med systemd[12156]: Reached target Sockets.
Dec 19 11:56:50 dgt-med systemd[12156]: Starting Basic System.
Dec 19 11:56:50 dgt-med systemd[12156]: Reached target Basic System.
Dec 19 11:56:50 dgt-med systemd[12156]: Starting Default.
Dec 19 11:56:50 dgt-med systemd[12156]: Reached target Default.
Dec 19 11:56:50 dgt-med systemd[12156]: Startup finished in 15ms.
Dec 19 11:56:50 dgt-med systemd[1]: Started Session 783 of user XXXXXXXX.
Dec 19 11:56:50 dgt-med systemd[1]: Started User Manager for UID XXXXX.
Dec 19 13:51:52 dgt-med systemd[1]: Starting Cleanup of Temporary Directories...
Dec 19 13:51:52 dgt-med systemd[1]: Started Cleanup of Temporary Directories.
Dec 20 13:52:02 dgt-med systemd[1]: Starting Cleanup of Temporary Directories...
Dec 20 13:52:02 dgt-med systemd[1]: Started Cleanup of Temporary Directories.
Dec 21 13:52:22 dgt-med systemd[1]: Starting Cleanup of Temporary Directories...
Dec 21 13:52:22 dgt-med systemd[1]: Started Cleanup of Temporary Directories.
Dec 22 13:52:42 dgt-med systemd[1]: Starting Cleanup of Temporary Directories...
Dec 22 13:52:42 dgt-med systemd[1]: Started Cleanup of Temporary Directories.
Dec 23 13:53:02 dgt-med systemd[1]: Starting Cleanup of Temporary Directories...
Dec 23 13:53:02 dgt-med systemd[1]: Started Cleanup of Temporary Directories.
Dec 24 13:53:22 dgt-med systemd[1]: Starting Cleanup of Temporary Directories...
Dec 24 13:53:22 dgt-med systemd[1]: Started Cleanup of Temporary Directories.
Dec 25 13:53:42 dgt-med systemd[1]: Starting Cleanup of Temporary Directories...
Dec 25 13:53:42 dgt-med systemd[1]: Started Cleanup of Temporary Directories.
CP> Je ne sais pas si les processus CRON sont une cause ou un symptome...
Si tu les kill (depuis une console ouverte avant qui continue de répondre), ça donne qqchose ?

Alors là, je suis vraiment désolé, mais j'ai gardé une fenêtre root pendant
quelques jours, et je l'ai ensuite fermée en pensant que le problème était
réglé suite à une fausse piste (Nagios qui harcelait le port SSH).
Je donnerai des nouvelles au prochain plantage, mais d'ici là, s'il y a de
nouvelles idées...
Bonne journée,
Charles
--
Charles Plessy
Tsurumi, Kanagawa, Japon
Avatar
Charles Plessy
(Résumé des épisodes précédents, j'ai une machine virtuelle sur laquelle il
devient parfois impossible de se connecter. Les sessions existantes continuent
de fonctionner normalement, une grande partie des logs ne sont plus écrits, et
un processus cron par heure se lance, semble bloquer et s'accumule.)
Le 29/11/16 à 17:59, Charles Plessy a écrit :
>
> Je ne sais pas si les processus CRON sont une cause ou un symptome...

Le Wed, Nov 30, 2016 at 11:09:57AM +0100, Daniel Caillibaud a écrit :
Si tu les kill (depuis une console ouverte avant qui continue de répondre), ça donne qqchose ?


Le Mon, Dec 26, 2016 at 01:37:10PM +0900, Charles Plessy a écrit :
Alors là, je suis vraiment désolé, mais j'ai gardé une fenêtre root pendant
quelques jours, et je l'ai ensuite fermée en pensant que le problème était
réglé suite à une fausse piste (Nagios qui harcelait le port SSH).
Je donnerai des nouvelles au prochain plantage, mais d'ici là, s'il y a de
nouvelles idées...

Il a fallu attendre, mais le plantage nouveau est arrivé.
`killall cron` enlève toutes les tâches cron bloquées, mais il est toujours
impossible de se connecter. C'est donc un symptôme et pas une cause.
Dans kern.log, je note:
Mar 14 11:51:56 dgt-med vmunix: [3190021.268633] rsession invoked oom-killer: gfp_mask=0x50, order=0, oom_score_adj=0
Mar 14 11:51:57 dgt-med vmunix: [3190021.268637] rsession cpuset=dgt-med mems_allowed=0-1
Mar 14 11:51:57 dgt-med vmunix: [3190021.268644] Hardware name: Dell Inc. C6100 /0D61XP, BIOS 1.71 09/17/2013
Mar 14 11:51:57 dgt-med vmunix: [3190021.268645] ffff8817baf44c00 ffff880767c53c30 ffffffff8176534f ffff88114c2b1460
Mar 14 11:51:57 dgt-med vmunix: [3190021.268648] ffff880767c53cb8 ffffffff8175ef1f 0000000000000303 ffff880767c53c58
Mar 14 11:51:57 dgt-med vmunix: [3190021.268650] ffff880767c53c80 ffffffff81164f07 ffff882fb90fd638 ffff882fb90fd180
Mar 14 11:51:57 dgt-med vmunix: [3190021.268652] Call Trace:
Mar 14 11:51:57 dgt-med vmunix: [3190021.268660] [<ffffffff8176534f>] dump_stack+0x45/0x56
Mar 14 11:51:57 dgt-med vmunix: [3190021.268664] [<ffffffff8175ef1f>] dump_header+0x7f/0x1f1
Mar 14 11:51:57 dgt-med vmunix: [3190021.268671] [<ffffffff81165385>] oom_kill_process+0x205/0x360
Mar 14 11:51:57 dgt-med vmunix: [3190021.268678] [<ffffffff812eb665>] ? security_capable_noaudit+0x15/0x20
Mar 14 11:51:57 dgt-med vmunix: [3190021.268684] [<ffffffff811c9660>] ? mem_cgroup_try_charge_mm+0xa0/0xa0
Mar 14 11:51:57 dgt-med vmunix: [3190021.268689] [<ffffffff8175d5c9>] mm_fault_error+0x67/0x140
Mar 14 12:06:25 dgt-med vmunix: [3190890.132369] rsession invoked oom-killer: gfp_mask=0x50, order=0, oom_score_adj=0
Mar 14 12:06:25 dgt-med vmunix: [3190890.132377] CPU: 5 PID: 10550 Comm: rsession Tainted: P OE 3.16.0-38-generic #5
Mar 14 12:06:25 dgt-med vmunix: [3190890.132379] Hardware name: Dell Inc. C6100 /0D61XP, BIOS 1.71 09/17/2013
Mar 14 12:06:25 dgt-med vmunix: [3190890.132380] ffff8817baf44c00 ffff8816d3f5bc30 ffffffff8176534f ffff8818937065e0
Mar 14 12:06:25 dgt-med vmunix: [3190890.132383] ffff8816d3f5bcb8 ffffffff8175ef1f 00000000000000e1 ffff8816d3f5bc58
Mar 14 12:06:25 dgt-med vmunix: [3190890.132385] ffff8816d3f5bc80 ffffffff81164f07 ffff882fb90fd638 ffff882fb90fd180
Mar 14 12:06:25 dgt-med vmunix: [3190890.132387] Call Trace:
Mar 14 12:06:25 dgt-med vmunix: [3190890.132395] [<ffffffff8176534f>] dump_stack+0x45/0x56
Mar 14 12:06:25 dgt-med vmunix: [3190890.132399] [<ffffffff8175ef1f>] dump_header+0x7f/0x1f1
Mar 14 12:06:25 dgt-med vmunix: [3190890.132406] [<ffffffff81165385>] oom_kill_process+0x205/0x360
Mar 14 12:06:25 dgt-med vmunix: [3190890.132414] [<ffffffff812eb665>] ? security_capable_noaudit+0x15/0x20
Mar 14 12:06:25 dgt-med vmunix: [3190890.132419] [<ffffffff811c9660>] ? mem_cgroup_try_charge_mm+0xa0/0xa0
Mar 14 12:06:25 dgt-med vmunix: [3190890.132425] [<ffffffff8175d5c9>] mm_fault_error+0x67/0x140
Mar 14 13:17:30 dgt-med vmunix: [3195156.740895] CPU: 1 PID: 6581 Comm: rstudio Tainted: P OE 3.16.0-38-generic #52~
Mar 14 13:17:30 dgt-med vmunix: [3195156.740898] ffff8817baf44c00 ffff881f48137c30 ffffffff8176534f ffff882fb13e28c0
Mar 14 13:17:30 dgt-med vmunix: [3195156.740901] ffff881f48137c80 ffffffff81164f07 ffff882c2cfae068 ffff882c2cfadbb0
Mar 14 13:17:30 dgt-med vmunix: [3195156.740910] [<ffffffff8176534f>] dump_stack+0x45/0x56
Mar 14 13:17:30 dgt-med vmunix: [3195156.740917] [<ffffffff81164f07>] ? find_lock_task_mm+0x47/0xa0
Mar 14 13:17:30 dgt-med vmunix: [3195156.740923] [<ffffffff811c5e7b>] ? mem_cgroup_iter+0x14b/0x320
Mar 14 13:17:30 dgt-med vmunix: [3195156.740927] [<ffffffff811ca181>] mem_cgroup_oom_synchronize+0x581/0x5e0
Mar 14 13:17:30 dgt-med vmunix: [3195156.740932] [<ffffffff81165b84>] pagefault_out_of_memory+0x14/0x80
Mar 14 13:17:30 dgt-med vmunix: [3195156.740938] [<ffffffff8105b23c>] __do_page_fault+0x4ec/0x560
Mar 14 13:17:30 dgt-med vmunix: [3195156.740944] [<ffffffff810a7dd5>] ? set_next_entity+0x95/0xb0
Mar 14 13:17:30 dgt-med vmunix: [3195156.740948] [<ffffffff8105b2e1>] do_page_fault+0x31/0x70
Mar 14 13:17:30 dgt-med vmunix: [3195156.740951] Task in /lxc/dgt-med killed as a result of limit of /lxc/dgt-med
(rsession et rstudio font partie de la même application graphique pour de
l'analyse de données, https://www.rstudio.com/).
Il me semble que chaque fois que le problème arrive, la machine a été stressée
sur ses ressources. Se pourrait-il qu'un processus essentiel pour établir des
nouvelles connections soit interrompu ou bloqué dans ces moment, et pas ou mal
relancé ensuite ?
:~# ps aux | grep root
root 1 0.0 0.0 28544 3360 ? Ss Feb07 0:30 /sbin/init
root 140 0.0 0.0 32968 2448 ? Ss Feb07 0:05 /lib/systemd/systemd-journald
root 466 0.0 0.0 37096 168 ? Ss Feb07 0:04 /sbin/rpcbind -w
root 501 0.0 0.0 27568 0 ? Ss Feb07 0:00 /usr/sbin/rpc.idmapd
root 536 0.0 0.0 55184 1520 ? Ss Feb07 0:00 /usr/sbin/sshd -D
root 550 0.2 0.0 65352 13036 ? Ssl Feb07 109:52 /usr/bin/gitlab-ci-multi-runner run --working-directory /var/lib/gitlab-runner --config /etc/gitlab-runner/config.toml --service gitlab-runner --syslog --user gitlab-runner
root 614 0.0 0.0 28324 524 ? Ss Feb07 0:05 /lib/systemd/systemd-logind
root 700 0.0 0.0 95260 352 ? Ss Feb07 1:07 /usr/sbin/apache2 -k start
root 807 0.0 0.0 12652 1100 ? S Feb07 0:04 /usr/sbin/syslogd --no-forward
root 1165 0.0 0.0 12664 12 tty1 Ss+ Feb07 0:00 /sbin/agetty --noclear tty1 linux
root 1173 0.0 0.0 12664 12 ? Ss Feb07 0:00 /sbin/agetty --noclear tty2 linux
root 1181 0.0 0.0 12664 12 tty3 Ss+ Feb07 0:00 /sbin/agetty --noclear tty3 linux
root 1189 0.0 0.0 12664 12 tty4 Ss+ Feb07 0:00 /sbin/agetty --noclear tty4 linux
root 1197 0.0 0.0 16880 12 ? Ss Feb07 0:00 /sbin/agetty --noclear --keep-baud pts/3 115200 38400 9600 vt102
root 1205 0.0 0.0 16880 12 ? Ss Feb07 0:00 /sbin/agetty --noclear --keep-baud pts/2 115200 38400 9600 vt102
root 1213 0.0 0.0 16880 12 pts/1 Ss+ Feb07 0:00 /sbin/agetty --noclear --keep-baud pts/1 115200 38400 9600 vt102
root 1221 0.0 0.0 16880 12 ? Ss Feb07 0:00 /sbin/agetty --noclear --keep-baud pts/0 115200 38400 9600 vt102
root 1229 0.0 0.0 16880 12 console Ss+ Feb07 0:00 /sbin/agetty --noclear --keep-baud console 115200 38400 9600 vt102
root 1566 0.0 0.0 95352 12 ? Ss Feb07 0:00 sshd: plessy [priv]
root 1607 0.0 0.0 60108 12 pts/4 S Feb07 0:00 sudo su -
root 1608 0.0 0.0 61592 0 pts/4 S Feb07 0:00 su -
root 1609 0.0 0.0 26248 4296 pts/4 S Feb07 0:00 -su
root 1646 0.0 0.0 60108 12 pts/6 S Feb07 0:00 sudo su -
root 1647 0.0 0.0 61592 0 pts/6 S Feb07 0:00 su -
root 1648 0.0 0.0 26212 0 pts/6 S+ Feb07 0:00 -su
root 2754 0.0 0.0 21716 2504 pts/4 R+ 11:23 0:00 ps aux
root 2755 0.0 0.0 15344 1784 pts/4 S+ 11:23 0:00 grep root
root 16949 0.0 0.0 95352 12 ? Ss Mar06 0:00 sshd: plessy [priv]
root 18795 0.0 0.0 95352 12 ? Ss Mar06 0:00 sshd: plessy [priv]
root 22802 0.0 0.0 95352 20 ? Ss Mar07 0:00 sshd: plessy [priv]
Je vais devoir relancer la machine (j'en ai besoin), mais les commentaires sont
quand-meme les bienvenus.
Bonne journée,
--
Charles
Avatar
Charles Plessy
Le Thu, Mar 16, 2017 at 11:27:02AM +0900, Charles Plessy a écrit :
Il me semble que chaque fois que le problème arrive, la machine a été stressée
sur ses ressources. Se pourrait-il qu'un processus essentiel pour établir des
nouvelles connections soit interrompu ou bloqué dans ces moment, et pas ou mal
relancé ensuite ?
:~# ps aux | grep root
root 1 0.0 0.0 28544 3360 ? Ss Feb07 0:30 /sbin/init
root 140 0.0 0.0 32968 2448 ? Ss Feb07 0:05 /lib/systemd/systemd-journald
root 466 0.0 0.0 37096 168 ? Ss Feb07 0:04 /sbin/rpcbind -w
root 501 0.0 0.0 27568 0 ? Ss Feb07 0:00 /usr/sbin/rpc.idmapd
root 536 0.0 0.0 55184 1520 ? Ss Feb07 0:00 /usr/sbin/sshd -D
root 550 0.2 0.0 65352 13036 ? Ssl Feb07 109:52 /usr/bin/gitlab-ci-multi-runner run --working-directory /var/lib/gitlab-runner --config /etc/gitlab-runner/config.toml --service gitlab-runner --syslog --user gitlab-runner
root 614 0.0 0.0 28324 524 ? Ss Feb07 0:05 /lib/systemd/systemd-logind
root 700 0.0 0.0 95260 352 ? Ss Feb07 1:07 /usr/sbin/apache2 -k start
root 807 0.0 0.0 12652 1100 ? S Feb07 0:04 /usr/sbin/syslogd --no-forward
root 1165 0.0 0.0 12664 12 tty1 Ss+ Feb07 0:00 /sbin/agetty --noclear tty1 linux
root 1173 0.0 0.0 12664 12 ? Ss Feb07 0:00 /sbin/agetty --noclear tty2 linux
root 1181 0.0 0.0 12664 12 tty3 Ss+ Feb07 0:00 /sbin/agetty --noclear tty3 linux
root 1189 0.0 0.0 12664 12 tty4 Ss+ Feb07 0:00 /sbin/agetty --noclear tty4 linux
root 1197 0.0 0.0 16880 12 ? Ss Feb07 0:00 /sbin/agetty --noclear --keep-baud pts/3 115200 38400 9600 vt102
root 1205 0.0 0.0 16880 12 ? Ss Feb07 0:00 /sbin/agetty --noclear --keep-baud pts/2 115200 38400 9600 vt102
root 1213 0.0 0.0 16880 12 pts/1 Ss+ Feb07 0:00 /sbin/agetty --noclear --keep-baud pts/1 115200 38400 9600 vt102
root 1221 0.0 0.0 16880 12 ? Ss Feb07 0:00 /sbin/agetty --noclear --keep-baud pts/0 115200 38400 9600 vt102
root 1229 0.0 0.0 16880 12 console Ss+ Feb07 0:00 /sbin/agetty --noclear --keep-baud console 115200 38400 9600 vt102
root 1566 0.0 0.0 95352 12 ? Ss Feb07 0:00 sshd: plessy [priv]
root 1607 0.0 0.0 60108 12 pts/4 S Feb07 0:00 sudo su -
root 1608 0.0 0.0 61592 0 pts/4 S Feb07 0:00 su -
root 1609 0.0 0.0 26248 4296 pts/4 S Feb07 0:00 -su
root 1646 0.0 0.0 60108 12 pts/6 S Feb07 0:00 sudo su -
root 1647 0.0 0.0 61592 0 pts/6 S Feb07 0:00 su -
root 1648 0.0 0.0 26212 0 pts/6 S+ Feb07 0:00 -su
root 2754 0.0 0.0 21716 2504 pts/4 R+ 11:23 0:00 ps aux
root 2755 0.0 0.0 15344 1784 pts/4 S+ 11:23 0:00 grep root
root 16949 0.0 0.0 95352 12 ? Ss Mar06 0:00 sshd: plessy [priv]
root 18795 0.0 0.0 95352 12 ? Ss Mar06 0:00 sshd: plessy [priv]
root 22802 0.0 0.0 95352 20 ? Ss Mar07 0:00 sshd: plessy [priv]

Je me réponds à moi-même: je ne vois rien après le redémarrage (ci-dessous) qui manquerait
avant (ci-dessus), si ce n'est cron que j'avais tué.
# ps aux | grep root
root 1 0.0 0.0 28520 4748 ? Ss Mar16 0:00 /sbin/init
root 140 0.0 0.0 32968 6380 ? Ss Mar16 0:00 /lib/systemd/systemd-journald
root 469 0.0 0.0 37096 2692 ? Ss Mar16 0:00 /sbin/rpcbind -w
root 501 0.0 0.0 27568 224 ? Ss Mar16 0:00 /usr/sbin/rpc.idmapd
root 522 0.0 0.0 30120 2764 ? Ss Mar16 0:00 /usr/sbin/cron -f
root 536 0.0 0.0 55184 5368 ? Ss Mar16 0:00 /usr/sbin/sshd -D
root 550 0.1 0.0 65096 23468 ? Ssl Mar16 2:03 /usr/bin/gitlab-ci-multi-runner run --working-directory /var/lib/gitlab-runner --config /etc/gitlab-runner/config.toml --service gitlab-runner --syslog --user gitlab-runner
root 590 0.0 0.0 28268 2856 ? Ss Mar16 0:00 /lib/systemd/systemd-logind
root 740 0.0 0.0 12652 2012 ? S Mar16 0:00 /usr/sbin/syslogd --no-forward
root 1058 0.0 0.0 12664 1872 ? Ss Mar16 0:00 /sbin/agetty --noclear tty1 linux
root 1066 0.0 0.0 12664 1876 tty2 Ss+ Mar16 0:00 /sbin/agetty --noclear tty2 linux
root 1074 0.0 0.0 12664 1852 tty3 Ss+ Mar16 0:00 /sbin/agetty --noclear tty3 linux
root 1082 0.0 0.0 12664 1884 ? Ss Mar16 0:00 /sbin/agetty --noclear tty4 linux
root 1095 0.0 0.0 16880 2220 pts/3 Ss+ Mar16 0:00 /sbin/agetty --noclear --keep-baud pts/3 115200 38400 9600 vt102
root 1103 0.0 0.0 16880 2200 ? Ss Mar16 0:00 /sbin/agetty --noclear --keep-baud pts/2 115200 38400 9600 vt102
root 1111 0.0 0.0 16880 2228 ? Ss Mar16 0:00 /sbin/agetty --noclear --keep-baud pts/1 115200 38400 9600 vt102
root 1119 0.0 0.0 16880 2224 pts/0 Ss+ Mar16 0:00 /sbin/agetty --noclear --keep-baud pts/0 115200 38400 9600 vt102
root 1127 0.0 0.0 16880 2220 console Ss+ Mar16 0:00 /sbin/agetty --noclear --keep-baud console 115200 38400 9600 vt102
root 1168 0.0 0.0 95248 8412 ? Ss Mar16 0:01 /usr/sbin/apache2 -k start
root 2185 0.0 0.0 95352 6252 ? Ss 09:34 0:00 sshd: plessy [priv]
root 2226 0.0 0.0 60108 4240 pts/4 S 09:34 0:00 sudo su -
root 2227 0.0 0.0 61592 3704 pts/4 S 09:34 0:00 su -
root 2228 0.0 0.0 26180 5420 pts/4 S 09:34 0:00 -su
root 2237 0.0 0.0 21716 2444 pts/4 R+ 09:34 0:00 ps aux
root 2238 0.0 0.0 15344 1760 pts/4 S+ 09:34 0:00 grep root
Bonne journée,
--
Charles
Avatar
Francois Lafont
Bonsoir,
Je n'ai pas d'idée précise sur ton souci, désolé. En revanche,
voici deux pistes pour tenter d'avoir plus d'éléments (enfin,
j'espère).
1. Peut-être devrais tu tenter de grapher la machine (par
exemple je crois que munin n'est pas très compliqué à mettre
en place). Peut-être que les graphes quelques minutes ou
quelques heures avant le « crash » t'indiqueront quelque
chose. Une petite supervision sur la machine également
pour avoir une idée du moment où elle plante pourrait aider.
2. Enfin, peut-être que le plantage entraîne le filesystem
en read only et que tu perds du coup des infos précieuses
qui ne peuvent être écrites dans les logs. Du coup, ça
pourrait être intéressant d'envoyer le syslog de la machine
sur le rsyslog d'une machine distante afin d'avoir une
chance de disposer des logs même au moment du plantage.
Voilà mes 2 centimes, rien d'extraordinaire.
Bon courage. :)
--
François Lafont
Avatar
Charles Plessy
Le 16/03/17 à 11:27, Charles Plessy a écrit :
CP>
CP> (Résumé des épisodes précédents, j'ai une machine virtuelle sur laquelle il
CP> devient parfois impossible de se connecter. Les sessions existantes continuent
CP> de fonctionner normalement, une grande partie des logs ne sont plus écrits, et
CP> un processus cron par heure se lance, semble bloquer et s'accumule.)

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``), ç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).

Merci beaucoup pour la suggestion (et merci aussi à François pour sa
réponse); c'est assez formidable de pouvoir faire un « top » à rebours !
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.
Un inspection avec atop de l'état de la machine au moment ou elle a
cessé d'enregistrer ses logs (sauf -- MARK --) ne montre rien de
spécial... Mais ceci dit merci encore de m'avoir fait apprendre atop.
Je ne comprends toujours pas ce qui peut empêcher la machine de créer de
nouvelles sessions alors qu'il y a assez de mémoire, d'espace disque et
de temps processeur...
Bonne journée,
Charles
--
Charles Plessy
Tsurumi, Kanagawa, Japon