Serveur bloqué par de multiples CRON -f ?

Le
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
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
randy11
Le #26419154
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
Daniel Caillibaud
Le #26419153
Le 29/11/16 à 17:59, Charles Plessy 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.
Charles Plessy
Le #26421535
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 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
Publicité
Poster une réponse
Anonyme