Je viens de migrer mon serveur de noms sous RedHat 8.0.
Voici ma config :
[...]
options {
directory "/var/named";
notify no;
forwarders {212.27.32.5;213.228.0.168;};
};
[...]
zone "maison" {
type master;
file "maison";
};
zone "1.168.192.IN-ADDR.ARPA" {
type master;
file "192.168.1";
};
[...]
L'accès aux serveurs DNS (forwarders) se fait par une passerelle et
n'est pas permanent (forfait RTC !). Le serveur de nom n'a pas
l'information de l'état de la passerelle (routage actif ou non).
Scénario :
- serveur> démarrage de named
- serveur> ping -c1 free.fr renvoie une erreur d'hôte inconnue
- passerelle> démarrage de la connexion et du routage
- serveur> ping -c1 free.fr s'effectue correctement
- passerelle> déconnexion et fin du routage
- serveur> ping -c1 free.fr BOUCLE avec destination unreachable, sur
l'ancienne ip résolue lors de la dernière connexion
- serveur> redémarrage de named
- serveur> ping -c1 free.fr renvoi IMMEDIATEMENT une erreur d'hôte inconnue
Que se passe-t-il ?
Named a-t-il un cache pour ses forwarders ?
Si oui, comment le forcer à les consulter pour chaque requête ?
Pour information, cette configuration fonctionnait sous Mandrake 7.0,
avant la migration sous RedHat 8.0.
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
shal
David LE BOURGEOIS wrote:
Bonjour à tous.
bonjour
Je viens de migrer mon serveur de noms sous RedHat 8.0. Voici ma config :
[...] options { directory "/var/named"; notify no; forwarders {212.27.32.5;213.228.0.168;}; }; [...] zone "maison" { type master; file "maison"; }; zone "1.168.192.IN-ADDR.ARPA" { type master; file "192.168.1"; }; [...]
L'accès aux serveurs DNS (forwarders) se fait par une passerelle et n'est pas permanent (forfait RTC !). Le serveur de nom n'a pas l'information de l'état de la passerelle (routage actif ou non).
Scénario : - serveur> démarrage de named - serveur> ping -c1 free.fr renvoie une erreur d'hôte inconnue - passerelle> démarrage de la connexion et du routage - serveur> ping -c1 free.fr s'effectue correctement - passerelle> déconnexion et fin du routage - serveur> ping -c1 free.fr BOUCLE avec destination unreachable, sur l'ancienne ip résolue lors de la dernière connexion - serveur> redémarrage de named - serveur> ping -c1 free.fr renvoi IMMEDIATEMENT une erreur d'hôte inconnue
Que se passe-t-il ?
Named a-t-il un cache pour ses forwarders ?
oui
Si oui, comment le forcer à les consulter pour chaque requête ?
rajoutez :
recursion no;
dans la partie option de named.conf. Mais bon les perfs vont s'ecrouler....
David LE BOURGEOIS wrote:
Bonjour à tous.
bonjour
Je viens de migrer mon serveur de noms sous RedHat 8.0.
Voici ma config :
[...]
options {
directory "/var/named";
notify no;
forwarders {212.27.32.5;213.228.0.168;};
};
[...]
zone "maison" {
type master;
file "maison";
};
zone "1.168.192.IN-ADDR.ARPA" {
type master;
file "192.168.1";
};
[...]
L'accès aux serveurs DNS (forwarders) se fait par une passerelle et
n'est pas permanent (forfait RTC !). Le serveur de nom n'a pas
l'information de l'état de la passerelle (routage actif ou non).
Scénario :
- serveur> démarrage de named
- serveur> ping -c1 free.fr renvoie une erreur d'hôte inconnue
- passerelle> démarrage de la connexion et du routage
- serveur> ping -c1 free.fr s'effectue correctement
- passerelle> déconnexion et fin du routage
- serveur> ping -c1 free.fr BOUCLE avec destination unreachable, sur
l'ancienne ip résolue lors de la dernière connexion
- serveur> redémarrage de named
- serveur> ping -c1 free.fr renvoi IMMEDIATEMENT une erreur d'hôte
inconnue
Que se passe-t-il ?
Named a-t-il un cache pour ses forwarders ?
oui
Si oui, comment le forcer à les consulter pour chaque requête ?
rajoutez :
recursion no;
dans la partie option de named.conf. Mais bon les perfs vont s'ecrouler....
Je viens de migrer mon serveur de noms sous RedHat 8.0. Voici ma config :
[...] options { directory "/var/named"; notify no; forwarders {212.27.32.5;213.228.0.168;}; }; [...] zone "maison" { type master; file "maison"; }; zone "1.168.192.IN-ADDR.ARPA" { type master; file "192.168.1"; }; [...]
L'accès aux serveurs DNS (forwarders) se fait par une passerelle et n'est pas permanent (forfait RTC !). Le serveur de nom n'a pas l'information de l'état de la passerelle (routage actif ou non).
Scénario : - serveur> démarrage de named - serveur> ping -c1 free.fr renvoie une erreur d'hôte inconnue - passerelle> démarrage de la connexion et du routage - serveur> ping -c1 free.fr s'effectue correctement - passerelle> déconnexion et fin du routage - serveur> ping -c1 free.fr BOUCLE avec destination unreachable, sur l'ancienne ip résolue lors de la dernière connexion - serveur> redémarrage de named - serveur> ping -c1 free.fr renvoi IMMEDIATEMENT une erreur d'hôte inconnue
Que se passe-t-il ?
Named a-t-il un cache pour ses forwarders ?
oui
Si oui, comment le forcer à les consulter pour chaque requête ?
rajoutez :
recursion no;
dans la partie option de named.conf. Mais bon les perfs vont s'ecrouler....
shal
David LE BOURGEOIS wrote:
Bonjour à tous.
bonjour,
Je viens de migrer mon serveur de noms sous RedHat 8.0. Voici ma config :
[...] options { directory "/var/named"; notify no; forwarders {212.27.32.5;213.228.0.168;}; }; [...] zone "maison" { type master; file "maison"; }; zone "1.168.192.IN-ADDR.ARPA" { type master; file "192.168.1"; }; [...]
L'accès aux serveurs DNS (forwarders) se fait par une passerelle et n'est pas permanent (forfait RTC !). Le serveur de nom n'a pas l'information de l'état de la passerelle (routage actif ou non).
Scénario : - serveur> démarrage de named - serveur> ping -c1 free.fr renvoie une erreur d'hôte inconnue - passerelle> démarrage de la connexion et du routage - serveur> ping -c1 free.fr s'effectue correctement - passerelle> déconnexion et fin du routage - serveur> ping -c1 free.fr BOUCLE avec destination unreachable, sur l'ancienne ip résolue lors de la dernière connexion - serveur> redémarrage de named - serveur> ping -c1 free.fr renvoi IMMEDIATEMENT une erreur d'hôte inconnue
Que se passe-t-il ?
Bind en tant que serveur recursif cache toujours.
Named a-t-il un cache pour ses forwarders ?
oui
Si oui, comment le forcer à les consulter pour chaque requête ?
Peut-être rajouter max-cache-ttl 1; max-ncache-ttl 1; dans la partie options de named.conf.
1 voir 0 mais je sais pas exactement ce qu'il fait dans le cas....
David LE BOURGEOIS wrote:
Bonjour à tous.
bonjour,
Je viens de migrer mon serveur de noms sous RedHat 8.0.
Voici ma config :
[...]
options {
directory "/var/named";
notify no;
forwarders {212.27.32.5;213.228.0.168;};
};
[...]
zone "maison" {
type master;
file "maison";
};
zone "1.168.192.IN-ADDR.ARPA" {
type master;
file "192.168.1";
};
[...]
L'accès aux serveurs DNS (forwarders) se fait par une passerelle et
n'est pas permanent (forfait RTC !). Le serveur de nom n'a pas
l'information de l'état de la passerelle (routage actif ou non).
Scénario :
- serveur> démarrage de named
- serveur> ping -c1 free.fr renvoie une erreur d'hôte inconnue
- passerelle> démarrage de la connexion et du routage
- serveur> ping -c1 free.fr s'effectue correctement
- passerelle> déconnexion et fin du routage
- serveur> ping -c1 free.fr BOUCLE avec destination unreachable, sur
l'ancienne ip résolue lors de la dernière connexion
- serveur> redémarrage de named
- serveur> ping -c1 free.fr renvoi IMMEDIATEMENT une erreur d'hôte
inconnue
Que se passe-t-il ?
Bind en tant que serveur recursif cache toujours.
Named a-t-il un cache pour ses forwarders ?
oui
Si oui, comment le forcer à les consulter pour chaque requête ?
Peut-être rajouter
max-cache-ttl 1;
max-ncache-ttl 1;
dans la partie options de named.conf.
1 voir 0 mais je sais pas exactement ce qu'il fait dans le cas....
Je viens de migrer mon serveur de noms sous RedHat 8.0. Voici ma config :
[...] options { directory "/var/named"; notify no; forwarders {212.27.32.5;213.228.0.168;}; }; [...] zone "maison" { type master; file "maison"; }; zone "1.168.192.IN-ADDR.ARPA" { type master; file "192.168.1"; }; [...]
L'accès aux serveurs DNS (forwarders) se fait par une passerelle et n'est pas permanent (forfait RTC !). Le serveur de nom n'a pas l'information de l'état de la passerelle (routage actif ou non).
Scénario : - serveur> démarrage de named - serveur> ping -c1 free.fr renvoie une erreur d'hôte inconnue - passerelle> démarrage de la connexion et du routage - serveur> ping -c1 free.fr s'effectue correctement - passerelle> déconnexion et fin du routage - serveur> ping -c1 free.fr BOUCLE avec destination unreachable, sur l'ancienne ip résolue lors de la dernière connexion - serveur> redémarrage de named - serveur> ping -c1 free.fr renvoi IMMEDIATEMENT une erreur d'hôte inconnue
Que se passe-t-il ?
Bind en tant que serveur recursif cache toujours.
Named a-t-il un cache pour ses forwarders ?
oui
Si oui, comment le forcer à les consulter pour chaque requête ?
Peut-être rajouter max-cache-ttl 1; max-ncache-ttl 1; dans la partie options de named.conf.
1 voir 0 mais je sais pas exactement ce qu'il fait dans le cas....
David LE BOURGEOIS
David LE BOURGEOIS wrote:
Si oui, comment le forcer à les consulter pour chaque requête ?
Peut-être rajouter max-cache-ttl 1; max-ncache-ttl 1; dans la partie options de named.conf.
1 voir 0 mais je sais pas exactement ce qu'il fait dans le cas....
J'ai effectué les tests avec 1, puis 0. Mais aucun ne semble désactiver le cache.
Je continue mes recherches...
-- David LE BOURGEOIS
David LE BOURGEOIS wrote:
Si oui, comment le forcer à les consulter pour chaque requête ?
Peut-être rajouter
max-cache-ttl 1;
max-ncache-ttl 1;
dans la partie options de named.conf.
1 voir 0 mais je sais pas exactement ce qu'il fait dans le cas....
J'ai effectué les tests avec 1, puis 0.
Mais aucun ne semble désactiver le cache.
Si oui, comment le forcer à les consulter pour chaque requête ?
Peut-être rajouter max-cache-ttl 1; max-ncache-ttl 1; dans la partie options de named.conf.
1 voir 0 mais je sais pas exactement ce qu'il fait dans le cas....
J'ai effectué les tests avec 1, puis 0. Mais aucun ne semble désactiver le cache.
Je continue mes recherches...
Tu peux mettre recursion no; dans named.conf il n'y aura plus de cache mais plus de resolution non plus......
La manip que je te donnais permetter juste que le cache ne grader les données que 1 seconde et ensuite au besoin il refait la resolution.
A+
TiChou
Dans l'article news:4038d2ca$0$29927$, David LE BOURGEOIS écrivait :
Bonjour à tous.
Bonsoir,
Je viens de migrer mon serveur de noms sous RedHat 8.0. Voici ma config :
[snip]
L'accès aux serveurs DNS (forwarders) se fait par une passerelle et n'est pas permanent (forfait RTC !). Le serveur de nom n'a pas l'information de l'état de la passerelle (routage actif ou non).
Scénario : - serveur> démarrage de named - serveur> ping -c1 free.fr renvoie une erreur d'hôte inconnue
Normal.
- passerelle> démarrage de la connexion et du routage - serveur> ping -c1 free.fr s'effectue correctement
Normal.
- passerelle> déconnexion et fin du routage - serveur> ping -c1 free.fr BOUCLE avec destination unreachable, sur l'ancienne ip résolue lors de la dernière connexion
Normal.
- serveur> redémarrage de named - serveur> ping -c1 free.fr renvoi IMMEDIATEMENT une erreur d'hôte inconnue
Normal.
Que se passe-t-il ?
Rien de particulier, pourquoi ?
Named a-t-il un cache pour ses forwarders ?
Oui, Bind cache, c'est un fonctionnement normal et logique.
Si oui, comment le forcer à les consulter pour chaque requête ?
Pourquoi vouloir le forcer à ignorer ce qu'il y a en cache alors que tout l'intérêt est de "cacher" au mieux les requêtes ?
Pour information, cette configuration fonctionnait sous Mandrake 7.0, avant la migration sous RedHat 8.0.
Et elle fonctionne sous votre RedHat 8.0.
-- TiChou
Dans l'article news:4038d2ca$0$29927$626a14ce@news.free.fr,
David LE BOURGEOIS <this.address@is.invalid> écrivait :
Bonjour à tous.
Bonsoir,
Je viens de migrer mon serveur de noms sous RedHat 8.0.
Voici ma config :
[snip]
L'accès aux serveurs DNS (forwarders) se fait par une passerelle et
n'est pas permanent (forfait RTC !). Le serveur de nom n'a pas
l'information de l'état de la passerelle (routage actif ou non).
Scénario :
- serveur> démarrage de named
- serveur> ping -c1 free.fr renvoie une erreur d'hôte inconnue
Normal.
- passerelle> démarrage de la connexion et du routage
- serveur> ping -c1 free.fr s'effectue correctement
Normal.
- passerelle> déconnexion et fin du routage
- serveur> ping -c1 free.fr BOUCLE avec destination unreachable, sur
l'ancienne ip résolue lors de la dernière connexion
Normal.
- serveur> redémarrage de named
- serveur> ping -c1 free.fr renvoi IMMEDIATEMENT une erreur d'hôte
inconnue
Normal.
Que se passe-t-il ?
Rien de particulier, pourquoi ?
Named a-t-il un cache pour ses forwarders ?
Oui, Bind cache, c'est un fonctionnement normal et logique.
Si oui, comment le forcer à les consulter pour chaque requête ?
Pourquoi vouloir le forcer à ignorer ce qu'il y a en cache alors que tout
l'intérêt est de "cacher" au mieux les requêtes ?
Pour information, cette configuration fonctionnait sous Mandrake 7.0,
avant la migration sous RedHat 8.0.
Dans l'article news:4038d2ca$0$29927$, David LE BOURGEOIS écrivait :
Bonjour à tous.
Bonsoir,
Je viens de migrer mon serveur de noms sous RedHat 8.0. Voici ma config :
[snip]
L'accès aux serveurs DNS (forwarders) se fait par une passerelle et n'est pas permanent (forfait RTC !). Le serveur de nom n'a pas l'information de l'état de la passerelle (routage actif ou non).
Scénario : - serveur> démarrage de named - serveur> ping -c1 free.fr renvoie une erreur d'hôte inconnue
Normal.
- passerelle> démarrage de la connexion et du routage - serveur> ping -c1 free.fr s'effectue correctement
Normal.
- passerelle> déconnexion et fin du routage - serveur> ping -c1 free.fr BOUCLE avec destination unreachable, sur l'ancienne ip résolue lors de la dernière connexion
Normal.
- serveur> redémarrage de named - serveur> ping -c1 free.fr renvoi IMMEDIATEMENT une erreur d'hôte inconnue
Normal.
Que se passe-t-il ?
Rien de particulier, pourquoi ?
Named a-t-il un cache pour ses forwarders ?
Oui, Bind cache, c'est un fonctionnement normal et logique.
Si oui, comment le forcer à les consulter pour chaque requête ?
Pourquoi vouloir le forcer à ignorer ce qu'il y a en cache alors que tout l'intérêt est de "cacher" au mieux les requêtes ?
Pour information, cette configuration fonctionnait sous Mandrake 7.0, avant la migration sous RedHat 8.0.
Et elle fonctionne sous votre RedHat 8.0.
-- TiChou
David LE BOURGEOIS
Dans l'article news:4038d2ca$0$29927$, David LE BOURGEOIS écrivait :
Bonjour à tous.
Bonsoir,
Je viens de migrer mon serveur de noms sous RedHat 8.0. Voici ma config :
[snip]
L'accès aux serveurs DNS (forwarders) se fait par une passerelle et n'est pas permanent (forfait RTC !). Le serveur de nom n'a pas l'information de l'état de la passerelle (routage actif ou non).
Scénario : - serveur> démarrage de named - serveur> ping -c1 free.fr renvoie une erreur d'hôte inconnue
Normal.
- passerelle> démarrage de la connexion et du routage - serveur> ping -c1 free.fr s'effectue correctement
Normal.
- passerelle> déconnexion et fin du routage - serveur> ping -c1 free.fr BOUCLE avec destination unreachable, sur l'ancienne ip résolue lors de la dernière connexion
Normal.
Le problème est que ping, en bouclant, ne rend pas la main. Or sur le serveur tournent des crontabs du genre :
Donc au bout d'un certain temps, le serveur se retrouve avec des processus qui ne se terminent pas
- serveur> redémarrage de named - serveur> ping -c1 free.fr renvoi IMMEDIATEMENT une erreur d'hôte inconnue
Normal.
Que se passe-t-il ?
Rien de particulier, pourquoi ?
Parce que je voudrais que le ping se termine immédiatement, sans avoir pour cela à redémarrer named.
Named a-t-il un cache pour ses forwarders ?
Oui, Bind cache, c'est un fonctionnement normal et logique.
Si oui, comment le forcer à les consulter pour chaque requête ?
Pourquoi vouloir le forcer à ignorer ce qu'il y a en cache alors que tout l'intérêt est de "cacher" au mieux les requêtes ?
Pour information, cette configuration fonctionnait sous Mandrake 7.0, avant la migration sous RedHat 8.0.
Et elle fonctionne sous votre RedHat 8.0.
La solution que j'ai trouvée est d'ajouter l'option -w au ping :
ping -c1 -w1 free.fr && echo INTERNET ACCESSIBLE
Merci pour les réponses qui m'ont aiguillé vers le manuel de ping.
-- David LE BOURGEOIS
Dans l'article news:4038d2ca$0$29927$626a14ce@news.free.fr,
David LE BOURGEOIS <this.address@is.invalid> écrivait :
Bonjour à tous.
Bonsoir,
Je viens de migrer mon serveur de noms sous RedHat 8.0.
Voici ma config :
[snip]
L'accès aux serveurs DNS (forwarders) se fait par une passerelle et
n'est pas permanent (forfait RTC !). Le serveur de nom n'a pas
l'information de l'état de la passerelle (routage actif ou non).
Scénario :
- serveur> démarrage de named
- serveur> ping -c1 free.fr renvoie une erreur d'hôte inconnue
Normal.
- passerelle> démarrage de la connexion et du routage
- serveur> ping -c1 free.fr s'effectue correctement
Normal.
- passerelle> déconnexion et fin du routage
- serveur> ping -c1 free.fr BOUCLE avec destination unreachable, sur
l'ancienne ip résolue lors de la dernière connexion
Normal.
Le problème est que ping, en bouclant, ne rend pas la main.
Or sur le serveur tournent des crontabs du genre :
Dans l'article news:4038d2ca$0$29927$, David LE BOURGEOIS écrivait :
Bonjour à tous.
Bonsoir,
Je viens de migrer mon serveur de noms sous RedHat 8.0. Voici ma config :
[snip]
L'accès aux serveurs DNS (forwarders) se fait par une passerelle et n'est pas permanent (forfait RTC !). Le serveur de nom n'a pas l'information de l'état de la passerelle (routage actif ou non).
Scénario : - serveur> démarrage de named - serveur> ping -c1 free.fr renvoie une erreur d'hôte inconnue
Normal.
- passerelle> démarrage de la connexion et du routage - serveur> ping -c1 free.fr s'effectue correctement
Normal.
- passerelle> déconnexion et fin du routage - serveur> ping -c1 free.fr BOUCLE avec destination unreachable, sur l'ancienne ip résolue lors de la dernière connexion
Normal.
Le problème est que ping, en bouclant, ne rend pas la main. Or sur le serveur tournent des crontabs du genre :
Le problème que vous rencontrez ici n'a rien à voir avec un problème de fonctionnement de Bind, mais d'un problème de fonctionnement interne de la commande ping qui, quand elle est lancée par un processus père et quand le hôte contacté ne répond pas, ne sait effectivement plus rendre la main (pour rentrer un peu plus en détail, la commande ping utilise un timer interne (setitimer) qui a pour but de faire stopper une boucle en envoyant au process ping un signal de type SIGALRM, seulement ce signal est intercepté par le processus père et annulé, et on se retrouve alors dans une boucle infinie).
Donc au bout d'un certain temps, le serveur se retrouve avec des processus qui ne se terminent pas
Oui, ils ne se terminent pas d'eux même, il faut alors les forcer à se terminer avec un SIGKILL.
Que se passe-t-il ?
Rien de particulier, pourquoi ?
Parce que je voudrais que le ping se termine immédiatement, sans avoir pour cela à redémarrer named.
Il faut revoir le problème autrement, car de toute manière vous pouvez rencontrer le même problème du process ping ne se terminant pas alors que vous êtes bien connecté mais que le hôte pop.free.fr soit temporairement injoignable. D'ailleurs, pour vous en convaincre, je vous invite à faire deux tests :
- le même crontab en étant connecté mais sur hôte ne répondant pas au ping - le même crontab en étant connecté mais en faisant un ping non pas sur le nom de l'hôte mais sur son IP.
et vous vous rendrez alors compte que Bind n'a plus rien à voir avec le problème que vous rencontrez.
La solution que j'ai trouvée est d'ajouter l'option -w au ping :
ping -c1 -w1 free.fr && echo INTERNET ACCESSIBLE
C'est une solution effectivement. Mais je me pose tout de même une question sur la raison pour laquelle vous faites un ping pour décider ou non de lancer fetchmail. Pourquoi ne pas laisser fetchmail se lancer, sachant que si le serveur pop est injoignable, fetchmail s'arrêtera de lui même ? De plus il y a d'autre moyen plus efficace pour tester si une connexion Internet est opérationnelle ou non (test de l'interface, test de la passerelle du FAI, ...).
Merci pour les réponses qui m'ont aiguillé vers le manuel de ping.
De rien. :)
-- TiChou
Dans l'article news:4039126e$0$24925$626a14ce@news.free.fr,
David LE BOURGEOIS <this.address@is.invalid> écrivait :
Le problème est que ping, en bouclant, ne rend pas la main.
Or sur le serveur tournent des crontabs du genre :
Le problème que vous rencontrez ici n'a rien à voir avec un problème de
fonctionnement de Bind, mais d'un problème de fonctionnement interne de la
commande ping qui, quand elle est lancée par un processus père et quand le
hôte contacté ne répond pas, ne sait effectivement plus rendre la main (pour
rentrer un peu plus en détail, la commande ping utilise un timer interne
(setitimer) qui a pour but de faire stopper une boucle en envoyant au
process ping un signal de type SIGALRM, seulement ce signal est intercepté
par le processus père et annulé, et on se retrouve alors dans une boucle
infinie).
Donc au bout d'un certain temps, le serveur se retrouve avec des
processus qui ne se terminent pas
Oui, ils ne se terminent pas d'eux même, il faut alors les forcer à se
terminer avec un SIGKILL.
Que se passe-t-il ?
Rien de particulier, pourquoi ?
Parce que je voudrais que le ping se termine immédiatement, sans avoir
pour cela à redémarrer named.
Il faut revoir le problème autrement, car de toute manière vous pouvez
rencontrer le même problème du process ping ne se terminant pas alors que
vous êtes bien connecté mais que le hôte pop.free.fr soit temporairement
injoignable.
D'ailleurs, pour vous en convaincre, je vous invite à faire deux tests :
- le même crontab en étant connecté mais sur hôte ne répondant pas au ping
- le même crontab en étant connecté mais en faisant un ping non pas sur le
nom de l'hôte mais sur son IP.
et vous vous rendrez alors compte que Bind n'a plus rien à voir avec le
problème que vous rencontrez.
La solution que j'ai trouvée est d'ajouter l'option -w au ping :
ping -c1 -w1 free.fr && echo INTERNET ACCESSIBLE
C'est une solution effectivement.
Mais je me pose tout de même une question sur la raison pour laquelle vous
faites un ping pour décider ou non de lancer fetchmail. Pourquoi ne pas
laisser fetchmail se lancer, sachant que si le serveur pop est injoignable,
fetchmail s'arrêtera de lui même ?
De plus il y a d'autre moyen plus efficace pour tester si une connexion
Internet est opérationnelle ou non (test de l'interface, test de la
passerelle du FAI, ...).
Merci pour les réponses qui m'ont aiguillé vers le manuel de ping.
Le problème que vous rencontrez ici n'a rien à voir avec un problème de fonctionnement de Bind, mais d'un problème de fonctionnement interne de la commande ping qui, quand elle est lancée par un processus père et quand le hôte contacté ne répond pas, ne sait effectivement plus rendre la main (pour rentrer un peu plus en détail, la commande ping utilise un timer interne (setitimer) qui a pour but de faire stopper une boucle en envoyant au process ping un signal de type SIGALRM, seulement ce signal est intercepté par le processus père et annulé, et on se retrouve alors dans une boucle infinie).
Donc au bout d'un certain temps, le serveur se retrouve avec des processus qui ne se terminent pas
Oui, ils ne se terminent pas d'eux même, il faut alors les forcer à se terminer avec un SIGKILL.
Que se passe-t-il ?
Rien de particulier, pourquoi ?
Parce que je voudrais que le ping se termine immédiatement, sans avoir pour cela à redémarrer named.
Il faut revoir le problème autrement, car de toute manière vous pouvez rencontrer le même problème du process ping ne se terminant pas alors que vous êtes bien connecté mais que le hôte pop.free.fr soit temporairement injoignable. D'ailleurs, pour vous en convaincre, je vous invite à faire deux tests :
- le même crontab en étant connecté mais sur hôte ne répondant pas au ping - le même crontab en étant connecté mais en faisant un ping non pas sur le nom de l'hôte mais sur son IP.
et vous vous rendrez alors compte que Bind n'a plus rien à voir avec le problème que vous rencontrez.
La solution que j'ai trouvée est d'ajouter l'option -w au ping :
ping -c1 -w1 free.fr && echo INTERNET ACCESSIBLE
C'est une solution effectivement. Mais je me pose tout de même une question sur la raison pour laquelle vous faites un ping pour décider ou non de lancer fetchmail. Pourquoi ne pas laisser fetchmail se lancer, sachant que si le serveur pop est injoignable, fetchmail s'arrêtera de lui même ? De plus il y a d'autre moyen plus efficace pour tester si une connexion Internet est opérationnelle ou non (test de l'interface, test de la passerelle du FAI, ...).
Merci pour les réponses qui m'ont aiguillé vers le manuel de ping.
De rien. :)
-- TiChou
David LE BOURGEOIS
Dans l'article news:4039126e$0$24925$, David LE BOURGEOIS écrivait :
Rien de particulier, pourquoi ?
Parce que je voudrais que le ping se termine immédiatement, sans avoir pour cela à redémarrer named.
Il faut revoir le problème autrement, car de toute manière vous pouvez rencontrer le même problème du process ping ne se terminant pas alors que vous êtes bien connecté mais que le hôte pop.free.fr soit temporairement injoignable. D'ailleurs, pour vous en convaincre, je vous invite à faire deux tests :
- le même crontab en étant connecté mais sur hôte ne répondant pas au ping - le même crontab en étant connecté mais en faisant un ping non pas sur le nom de l'hôte mais sur son IP.
et vous vous rendrez alors compte que Bind n'a plus rien à voir avec le problème que vous rencontrez.
OK. Bind n'a effectivement rien a voir la dedans.
La solution que j'ai trouvée est d'ajouter l'option -w au ping :
ping -c1 -w1 free.fr && echo INTERNET ACCESSIBLE
C'est une solution effectivement. Mais je me pose tout de même une question sur la raison pour laquelle vous faites un ping pour décider ou non de lancer fetchmail. Pourquoi ne pas laisser fetchmail se lancer, sachant que si le serveur pop est injoignable, fetchmail s'arrêtera de lui même ?
Je pensais bien faire, puisque fetchmail va ramasser dans plusieurs boîtes aux lettres, chez différents fournisseur. Ainsi, pour une dizaine de fetchmail, je ne faisais qu'un test.
De plus il y a d'autre moyen plus efficace pour tester si une connexion Internet est opérationnelle ou non (test de l'interface, test de la passerelle du FAI, ...).
Pour le test de l'interface, comme c'est la passerelle qui se connecte, le serveur ne voit rien. Par contre, l'idée de la passerelle au lieu de free.fr me plait. C'est vrai que le jour où free.fr tombe par terre ne veut pas dire aucune connexion.
Merci encore.
-- David LE BOURGEOIS
Dans l'article news:4039126e$0$24925$626a14ce@news.free.fr,
David LE BOURGEOIS <this.address@is.invalid> écrivait :
Rien de particulier, pourquoi ?
Parce que je voudrais que le ping se termine immédiatement, sans avoir
pour cela à redémarrer named.
Il faut revoir le problème autrement, car de toute manière vous pouvez
rencontrer le même problème du process ping ne se terminant pas alors que
vous êtes bien connecté mais que le hôte pop.free.fr soit temporairement
injoignable.
D'ailleurs, pour vous en convaincre, je vous invite à faire deux tests :
- le même crontab en étant connecté mais sur hôte ne répondant pas au ping
- le même crontab en étant connecté mais en faisant un ping non pas sur le
nom de l'hôte mais sur son IP.
et vous vous rendrez alors compte que Bind n'a plus rien à voir avec le
problème que vous rencontrez.
OK. Bind n'a effectivement rien a voir la dedans.
La solution que j'ai trouvée est d'ajouter l'option -w au ping :
ping -c1 -w1 free.fr && echo INTERNET ACCESSIBLE
C'est une solution effectivement.
Mais je me pose tout de même une question sur la raison pour laquelle vous
faites un ping pour décider ou non de lancer fetchmail. Pourquoi ne pas
laisser fetchmail se lancer, sachant que si le serveur pop est injoignable,
fetchmail s'arrêtera de lui même ?
Je pensais bien faire, puisque fetchmail va ramasser dans plusieurs
boîtes aux lettres, chez différents fournisseur. Ainsi, pour une dizaine
de fetchmail, je ne faisais qu'un test.
De plus il y a d'autre moyen plus efficace pour tester si une connexion
Internet est opérationnelle ou non (test de l'interface, test de la
passerelle du FAI, ...).
Pour le test de l'interface, comme c'est la passerelle qui se connecte,
le serveur ne voit rien.
Par contre, l'idée de la passerelle au lieu de free.fr me plait. C'est
vrai que le jour où free.fr tombe par terre ne veut pas dire aucune
connexion.
Dans l'article news:4039126e$0$24925$, David LE BOURGEOIS écrivait :
Rien de particulier, pourquoi ?
Parce que je voudrais que le ping se termine immédiatement, sans avoir pour cela à redémarrer named.
Il faut revoir le problème autrement, car de toute manière vous pouvez rencontrer le même problème du process ping ne se terminant pas alors que vous êtes bien connecté mais que le hôte pop.free.fr soit temporairement injoignable. D'ailleurs, pour vous en convaincre, je vous invite à faire deux tests :
- le même crontab en étant connecté mais sur hôte ne répondant pas au ping - le même crontab en étant connecté mais en faisant un ping non pas sur le nom de l'hôte mais sur son IP.
et vous vous rendrez alors compte que Bind n'a plus rien à voir avec le problème que vous rencontrez.
OK. Bind n'a effectivement rien a voir la dedans.
La solution que j'ai trouvée est d'ajouter l'option -w au ping :
ping -c1 -w1 free.fr && echo INTERNET ACCESSIBLE
C'est une solution effectivement. Mais je me pose tout de même une question sur la raison pour laquelle vous faites un ping pour décider ou non de lancer fetchmail. Pourquoi ne pas laisser fetchmail se lancer, sachant que si le serveur pop est injoignable, fetchmail s'arrêtera de lui même ?
Je pensais bien faire, puisque fetchmail va ramasser dans plusieurs boîtes aux lettres, chez différents fournisseur. Ainsi, pour une dizaine de fetchmail, je ne faisais qu'un test.
De plus il y a d'autre moyen plus efficace pour tester si une connexion Internet est opérationnelle ou non (test de l'interface, test de la passerelle du FAI, ...).
Pour le test de l'interface, comme c'est la passerelle qui se connecte, le serveur ne voit rien. Par contre, l'idée de la passerelle au lieu de free.fr me plait. C'est vrai que le jour où free.fr tombe par terre ne veut pas dire aucune connexion.
