Pas de ping si j'utilise le CRON : */15 * * * *

Bonjour à tous,

Jeedom : 4.1.24 / Raspberry Pi OS 64 bits à jour de tout (détail sur le profil).

Sur un équipement Network, avec un ping vers une adresse externe :
Si j’utilise l’assistant de CRON pour : récurent 15 minutes, le paramétrage du CRON est alors à : */15 * * * * (ce qui est normal)
=> Mais le ping ne fonctionne plus automatiquement (pas de mise à jour de la date de collecte, ni de changement du temps de réponse par exemple).

J’ai testé avec :

* * * * * : ok
*/5 * * * * : ok (attendre au moins 15 minutes)
*/10 * * * * : ok (mais le temps est largement supérieur à 10, j'ai compté pratiquement 60 minutes
*/15 * * * * : ko

Est-il possible que cela soit un problème dans le plugin ?

Sur une autre commande ping, toujours avec le même plugin, dans les 2 cas, c’est pour faire un ping sur une adresse externe (mais je ne le souhaites pas toutes les minutes).
Le CRON */5 * * * * c’est plutôt toutes les 15 minutes que le ping s’effectue.

Ça peut faire un monter en charge toute le 15 minutes ?

Ta tester avec d’autre valeurs 11 12 13 30 ?

si non tu à ça :
0,15,30,45 * * * *

Salut,

J’ai testé de mon coté (sur une 4.1.24) et je ne reproduis pas le problème, le cron se déclenche comme voulu.

Par contre je vois que dans ton post il y a un erreur sur le cron, seulement 3 étoiles après le */15:

*/15 * * *

alors que lorsque l’on fait la config via l’assistant, il y a bien les 5 positions:

*/15 * * * *

as-tu tapé le cron à la main ou via l’assistant ?

pour info, l’assistant c’est le core qui le fourni, pas le plugin.

Si tu veux, en modifiant la fonction update avec celle-ci cela rajoute deux lignes de log en debug

	public static function update() {
		foreach (self::byType('networks') as $networks) {
			$autorefresh = $networks->getConfiguration('autorefresh');
			if ($networks->getIsEnable() == 1 && $autorefresh != '') {
				try {
                    log::add('networks', 'debug', "Vérification du cron de {$networks->getHumanName()} avec config: {$autorefresh}");
					$c = new Cron\CronExpression($autorefresh, new Cron\FieldFactory);
					if ($c->isDue()) {
                        log::add('networks', 'debug', "Auto-actualisation de {$networks->getHumanName()}");
						try {
							$networks->ping();
						} catch (Exception $exc) {
							log::add('networks', 'error', __('Erreur pour ', __FILE__) . $networks->getHumanName() . ' : ' . $exc->getMessage());
						}
					}
				} catch (Exception $exc) {
					log::add('networks', 'error', __('Expression cron non valide pour ', __FILE__) . $networks->getHumanName() . ' : ' . $autorefresh);
				}
			}
		}
	}

liste des équipements:

 log::add('networks', 'debug', "Vérification du cron de {$networks->getHumanName()} avec config: {$autorefresh}");

et log si on fait un ping:

log::add('networks', 'debug', "Auto-actualisation de {$networks->getHumanName()}");
1 « J'aime »

Bien vu tu a l’ zyeux

1 « J'aime »

Note que dans le titre le cron est correcte :wink:

2 « J'aime »

Bonjour à tous et merci de vos réponses.

C’est juste dans mon dernier exemple que j’ai oublié de saisir une *, mais j’utilise bien l’assistant pour faire la planification (j’ai pas fait de copier coller pour la rédaction).

Peut-être… que cela viens du fait que j’ai 23 équipements Network. Mais si j’utilise * * * * * c’est bien ok (pour les 23 équipements).

Alors que, pour ceux ou ne n’ai pas besoin de faire toutes les minutes, j’allège cela avec les /5, /10 et /15
Et c’est sur ceux la que j’ai des problèmes.

- Je vais tenter avec 12 par exemple, cela va l’empêcher de tomber sur les CRON 15.

Je note pour plus tard la modification du code, car je part en congé demain.

Ca ne change rien que ca soit un cron minute ou */15 ou */12 pour moi.
dans tous les cas c’est cette fonction « update » qui se lance toutes les minutes, qui vérifie si le cron est dû et lance le ping s’il faut.
Donc dans tous les cas il parcourt chaque minute tous tes équipements.

et le plugin a son propre cron (méthode update dans le moteur des tâches) donc il n’est pas influencé par les crons des autres plugins

Merci pour ces informations là.

Effectivement, toutes les 12 minutes n’a rien fait, l’exemple en cours : 14h55 ou j’ai forcé et rien depuis.

Je viens de repasser tout à : * * * * * , tout n’est pas non plus présent à la minute, mais cela me convient.

Je pense (mais pas sur) avoir trop d’équipement surveillés (23 en ce moment), et du coup, le ping n’a pas le temps de se faire partout dans la minute. Alors avec * * * * *, c’est entre 3 et 4 minutes pour avoir la réponse.

Il me semble me rappeler qu’un cron minute qui ne se finissait pas dans la minute pouvait empêcher le déclenchement d’autres crons.
Je ne sais pas si cela est toujours d’actualité.
Fait un essai en remplaçant les crons minute en crons deux minutes.

Je viens de tester cela ne change rien.
Je pense que le problème vient de ce que tu indiques, trop d’appareil à surveiller et du coup, cela n’arrive pas à aller jusqu’au bout dans la minute.
Si je met * * * * *, cela fait le tour en 3 minutes visiblement (c’est surement plus lent en plus, que la moitié ne répondent pas)
Si je met */2 * * * *, il faut dans les 5 minutes (pour ceux qui ont 2 minutes) pour répondre.

La vue dans le moteur des tâches parle d’elle même :

130073 | 18945 | 1 | networks | update * * * * * | 30 | 2021-07-24 20:48:02 | 130s | En cours

Il est toujours en cours.

Test en cours :
Je viens de faire une « découverte », j’ai désactivé 50% des équipements, en ne laissant que ceux qui répondent aux pings. Tout se fait en 2 secondes (l’ensemble) le CRON est fiable maintenant.
Les */2 * * * * en deux minutes, les * * * * * en 1 minute.

Je creuse pour savoir si c’est pas Ping et le mélange avec les requêtes ARP qui ralentie le tout.

1 « J'aime »

Bonsoir à tous

Bon, je viens de trouver l’origine de mon problème.

J’ai 23 équipements surveillés par un ping ou un ping sur le port de l’appareil (pour ceux qui ne savent pas répondre aux pings).
=> La tache dure entre 110 et 120 secondes (c’est tout le temps « en cours »).

J’ai désactivé tous les équipements qui en répondent pas à cet instant, il en reste 10.
=> La tâche dure maintenant entre 1 et 2 secondes (et les CROM sont OK) chaque minute et 2 secondes (top quoi).

A chaque fois que j’active un équipement, je prend entre 9 et 10 secondes de délais en plus, j’en active un 2ème, le moteur des tâches passe à 19 secondes.

Pour le moment, j’en conclus qu’un ping OK, c’est rapide, un ping qui ne répond pas, c’est 10 secondes.

Autre test, j’ai tenté de remplacer le PING par une requête ARP pour 1 appareil qui est actuellement à l’arrêt, c’est 30 secondes de plus pour le CRON QUE pour cet équipement. Je le repasse en PING et sauvegarde. La minute suivant, ce délais passe à 10 secondes (conforme aux tests précédents).

Pour le moment, j’en conclus qu’il est « peut être » possible d’améliorer l’attente quand un équipement ne répond pas.

Je viens d’allumer 7 caméras en principe à l’arrêt, le moteur des tâches passe à 1 s (il ne bouge pas en fait) et les pings sont complétés sur les 17 éléments actuellement allumés.

Je ne sais pas si c’est un problème ou pas (sur PC Windows, c’est pareil, la réponse est plus longue quand le PING ne répond pas), mais s’il est possible d’écouter cela, cela me serait grandement utile.

Bonsoir @Fabrice,
La commande utilisée dans le plugin est la suivante pour le ping

 ping -n -c 1 -t <TTL> <@IP>

le timeout par defaut est de 4000ms … donc si tu as bcp de matériels qui ne répondent pas, c’est 4s à chaque fois (le plugin a l’air de gérer les équipements en séquentiel, 1 ping puis 1 autre puis …)

tu peux sans doute essayer en modifiant la commande ping directement dans 3rdparty/networks_ping.class.php: en rajoutant le paramètre -W 1
(honnêtement, je n’ai jamais compris pourquoi le timeout par défaut de la commande ping était à 4s ! un appareil qui ne répond dans la second ne peut pas bien fonctionner

Norbert

Bonsoir,

Il n’aime pas cette modification, cela ne ping plus.
$exec_string = 'sudo ping -n -c 1 -t -W 1' . $ttl . ' ' . $host . ' 2> /dev/null';

A mettre entre le 1 et le -t (le -t doit preceder la variable $ttl)

Norbert

Bonsoir Fabrice

Tu peut aussi la jouer avec des scripts
et personnaliser les timings …

#/bin/bash

# This file is part of Jeedom.
#
# Jeedom is free software: you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation, either version 3 of the License, or
# (at your option) any later version.
#
# Jeedom is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with Jeedom. If not, see <http://www.gnu.org/licenses/>.

#Script shell permettant de savoir si une adresse mac ou ip est présente sur le réseaux
# Necessite arp-scan
# $1  : mac ou ip
# $2  : adresse
# Il faut ajouter les droits à apache (www-data) d'éxécuter la commande arp-scan
# Dans un terminal :
# sudo apt-get install arp-scan fping #installation du paquet permetant de scanner le réseaux et du paquet pour faire un ping rapide
# sudo visudo -s
# Ajouter la ligne :
# www-data ALL=NOPASSWD: /usr/bin/arp-scan
if [ "$1" = "mac" ]; then
        sudo /usr/sbin/arp-scan -l -g --retry=5 -T $2 -t 800 | grep -i $2 | wc -l
elif [ "$1" = "ip" ]; then
        #/usr/bin/fping -c1 -t500  $2 2>&1 | grep "min/avg/max" | wc -l
        /usr/bin/fping -c1 -t1000  $2 2>&1 | grep "min/avg/max" | wc -l
fi

A noter que si tu utilises la methode ARP, là, c’est 10s que tu te prends dans la vue. la commande utilisée est :

sudo arping -c 10 -C 1 -w 500000 <@IP>

le -c 10 correspond au nb de tentative avec un timeout de 1s pour chacune des tentatives …
à remplacer par :

sudo arping -c 1 -C 1 -w 500000 <@IP>

Norbert

Oui, j’ai testé avec ARP, c’est 30 secondes en vrais*. Comme le ping, c’est entre 9 et 10 secondes en vrais* (*en vrais = constaté via le plugin).

Avec ta modification :

$exec_string = 'sudo ping -n -c 1 -W 1 -t' . $ttl . ' ' . $host . ' 2> /dev/null';

J’ai réactivé l’ensemble des équipements pour tester et coupé les caméras (point de départ).
La commande passe en 75 secondes, au lieux de 140/150 sans le -W 1

En gros, c’est 2 fois plus rapide qu’avant, mais je reste toujours au dessus de 75 secondes au total.

J’ai fait le test en SSH :
sudo ping -n -c 1 -W 1 -t 1 192.168.0.1
=> Instantané (adresse existante)
sudo ping -n -c 1 -W 1 -t 1 192.168.0.11
=> (adresse inexistante) entre 1 et 2 secondes (à l’œil)

Donc il y a encore un truc qui semble (à la louche) doubler le temps par rapport aux commandes SSH.

Tu pourrais essayer de chopper un ping en cours d’exécution en lancant regulierement la commande :

ps -ef | grep ping

pour etre sur que c’est bien la commande que l’on attend ?
Tu as combien de matériels à pinguer ?
as-tu aussi modifé le arping ?

Norbert

Moi je fait cela

sudo arp-scan --localnet --retry=5   | sort -n -t . -k 1,1 -k 2,2 -k 3,3 -k 4,4

ça prend environ 7 secondes pour avoir tout mon réseau
environ 80 IP

après il faut trier les morceaux :wink: