Jump to content
FredP

Mon Démon S'arrête... (Résolu...)

Recommended Posts

Bonjour à tous,

Je me permets de me tourner vers vous car je commence sérieusement à craquer.

Je dispose depuis trois semaines d'un NAS TS-459.

Je ne suis pas un linuxien averti mais après de longs moments passés à comprendre comment une partie de ce système fonctionne, j'ai installé et configuré les serveurs Bind et DHCP des packages IPKG.

j'ai donc dû "patcher" le script Otpware.sh pour que les scripts de démarrage des packages IPKG soient lancés correctement à chaque démarrage.

Sur ce point pas de problème, chaque serveur se lance au démarrage de la machine, sans passer par un quelconque script type autorun.sh.

Mon serveur DNS tourne correctement et tout le temps, mais mon serveur DHCP s'endort ou s'arrête, sans doute tué par le "daemon_mgr".

Donc voilà ma question:

Comment puis-je faire pour que le daemon dhcpd ne soit pas arrêté ou endormi? En ajoutant une commande à mon script de démarrage (S56dhcp), par exemple?

Merci par avance.

Share this post


Link to post
Share on other sites

Bonjour,

Bonjour à tous,

Je me permets de me tourner vers vous car je commence sérieusement à craquer.

Je dispose depuis trois semaines d'un NAS TS-459.

Je ne suis pas un linuxien averti mais après de longs moments passés à comprendre comment une partie de ce système fonctionne, j'ai installé et configuré les serveurs Bind et DHCP des packages IPKG.

j'ai donc dû "patcher" le script Otpware.sh pour que les scripts de démarrage des packages IPKG soient lancés correctement à chaque démarrage.

Sur ce point pas de problème, chaque serveur se lance au démarrage de la machine, sans passer par un quelconque script type autorun.sh.

Mon serveur DNS tourne correctement et tout le temps, mais mon serveur DHCP s'endort ou s'arrête, sans doute tué par le "daemon_mgr".

Donc voilà ma question:

Comment puis-je faire pour que le daemon dhcpd ne soit pas arrêté ou endormi? En ajoutant une commande à mon script de démarrage (S56dhcp), par exemple?

Merci par avance.

Si daemon-mgr est fautif, vous devriez avoir des messages dans le log du qnap ...

car deamon_mgr ne prend pas (jamais a ma connaissance) l'initiative de "tuer" un job ... si on ne lui a pas demandé explicitement.

Le but de daemon_mgr est de lancer un programme comme un deamon et si celui-ci se plante, après quelques secondes, de relancer la même commande.

daemon_mgr ne stope un process lancé par lui que si la demande est explicite : daemon_mgr stop.

En cas d'arrêt intempestif d'un process sous son contrôle ... deamon_mgr génère un message de "re launch" visible dans le log (web admin)

Avez-vous eu des messages dans le log ?

Avez-vous une erreur dans dmesg ?

Avez-vous bien une ligne dhpcd dans /etc/daemon_mgr.conf

Avez-vous la même erreur en lançant à la main dhcpd sans passer par daemon_mgr ?

Le seul cas connu ou daemon_mgr se comporte anormalement est quand un daemon sous son contrôle, s'auto relance sans attendre que daemon_mgr le fasse, ceci génère des erreurs ... à éviter ....

Philippe.

NB si le script S56dhcp est celui d'origine ipkg, il ne doit pas utiliser daemon-mgr ????

Share this post


Link to post
Share on other sites

Bonjour Philippe,

Je crois que mon problème est résolu. Quelques tests restants pour les valider...

Share this post


Link to post
Share on other sites

Bonjour,

Bonjour Philippe,

Je crois que mon problème est résolu. Quelques tests restants pour les valider...

Bonne nouvelle ...

J'étais en attente de vos résultats avant de relancer la discussion ...

Vous n'auriez pas du supprimer votre message précédent, car instructif pour ceux qui auraient aussi a chercher une solution a un dysfonctionnement ... l'expérience de chacun est toujours utile.

N'hésitez pas a nous donner les raisons de vos problèmes, pour que d'autres évite l'écueil ... par exemple si le probléme venait du "port truncking" (puisque vous parlez de bond0) et du fait que dhcpd se met par défaut à l'écoute de tous les eth et bond ... c'est une erreur bonne à connaitre.

Philippe.

Share this post


Link to post
Share on other sites

Bonjour,

Désolé pour le post précédent, J'étais un tant soit peu énervé encore après une nuit blanche, mais je crois que je peux y remédier.

Déjà pour en revenir à mon choix, je me suis dit qu'utiliser un serveur DHCP récent dont je pourrais connaître le fonctionnalités qui y auront été intégrées me parait plus intéressant que chercher à deviner celles qui pourraient être intégrées dans celle du QNAP.

En plus je cherche à intégrer Bind, NTP et DHCP, donc....

Je dispose maintenant d'un serveur DHCP 4.1x qui fonctionne très bien maintenant et sur la distance puisque je l'ai vraiment titiller avec nos smartphones et une deuxième carte réseau qui équipe ma machine.

Mais nouveau problème, il ne se lance pas tout seul. possible pb avec le script de démarrage.

De mon expérience du serveur DHCP et de sa configuration:

- le script de démarrage fourni avec le package est largement insuffisant. pas de commande start, ni stop ou restart.... Ca manque cruellement de souplesse et je pense bloquer là dessus en ce moment. D'ailleurs, utilisé tel que, il ne fonctionne pas ou en tout cas pas en ce moment avec moi.

Le script que j'ai fait semble se lancer au démarrage comme un script shell, mais ce n'est pas pratique du tout.

_ Comme dans le script fourni avec le firmware du NAS, il faut absolument déclarer dans le fichier dhcpd.conf le ou les ports ethernet en écoute. Dans mon cas, il s'agit d'un port Trunk LACP, donc ce qu'il faut rajouter est:

DHCPD_INTERFACES="bond0";

Sans cette déclaration d'interface, le serveur démarre sans erreur mais ne fonctionne pas correctement et quand on fait un dhcpd stop, il signale l'absence de déclaration d'un port dans le fichier de conf et refuse de s'arrêter.

En général sur des distri, je crois que c'est dans Iptable que cette info est stockée, donc sur disque et inutile donc dans le serveur DHCP, là c'est difficile, une partie de la configuration du NAS est rechargée au démarrage. Ce qui m'a fait perdre du temps c'est qu'il existe selon les distris, différents mode de déclaration: INTERFACE, DHCPARGHHHHH :-) et que trouver la bonne est délicat.

Savoir sur quelle type de distri on travaille peut être bien utile pour retrouver ce genre d'infos et que rajouter un man bien rempli lors de la création des packages, c'est pas du luxe.

Je m'étais un peu énervé dans mon précédent post à propos des différentes distris, c'est pas très malin de ma part, mais ça, au bout de quelques jours...

De l'utilité ou pas de daemon_mgr:

Le script fourni par le firmware du NAS utilise le daemon_mgr, ce qui m'a un peu poussé à envisager de l'utiliser:

_ au départ parce que je ne savais pas comment les process et démons étaient gérés puis parce qu'il doit y avoir quand même une raison particulière pour ce service (je n'ai pas étudié tout le script)

_ Et puis, au moins pour m'assurer que le serveur DHCP du nas était arrêté;

Un petit script de Don sur le forum anglais donne:

une rapide commande à intégrer:

killdhcp()

{

      pid=`/bin/pidof dhcpd`

      if [ ! -z $pid ]; then

         kill $pid &>/dev/null

      fi

}

      /sbin/daemon_mgr dhcpd stop /usr/local/sbin/dhcpd

      rm -f /var/lock/subsys/dhcpd

Voilà de quoi s'assurer en principe que l'on n'a pas par inadvertance activé le srv DHCp du NAS: à ajouter dans le script DHCP du package ipkg, en début de la commande start()

_ enfin parce qu'il peut être une bonne source pour chercher les problèmes: le système de journal du NAS est très peu bavard mais en créant des erreurs avec un process géré par daemon_mgr, celui-ci se révèle suffisamment causant: pour les chercher, j'ai créer une erreur dans un process géré qui a fait relancer très souvent le daemon_mgr et rempli ma boite à lettres d'emails de notifications d'erreurs.

Pas très loquace mais je savais que le process se lançait...

Question syslog, il doit y avoir quelque chose à faire

Pour bien préparer tout ça, j'ai aussi forcé les chemins des différents fichiers au lancement d'une commande.

Exemple pour le fichier dhcpd.pid créé qui m'a régulièrement posé problème (puisqu'en "tuant" le démon, il restait là et impossible de relancer correctement le serveur.) j'ai forcé son chemin sur /var/run/dhcpd.pid**

Pour les fichiers de configuration ou de baux, idem, j'ai forcé des chemins pour pouvoir jongler entre plusieurs fichiers. Deux fichiers de configuration par exemple dhcpd1.conf et dhcpd2.conf pour repérer les erreurs qui pouvaient se produire. D'ailleurs, je crois avoir remarqué q'une des deux versions du serveur DHCP n'aiamit pas les adresses fixées liées à des noms d'hotes du type "totot.mondaine.intra". Donc je suis repassé à des adresses IP pour chaque hôte d'adresse "statique".

Vient maintenant pour être lancé, la question du chemin à utiliser dans un script.

Un NAS démarré permet de lancer une commande: /opt/sbin/dhcpd -cf /opt/etc/dhcpd.conf -lf /opt/etc/dhcpd.leases -pf /var/run/dhcpd.id bond0

En rajoutant -d, mode debug je suppose, on voit s'afficher sur la console ce que fait le serveur; Bien pratique!

Des paths....

Personnellement, j'ai préféré utiliser dans ma préparation, les chemins complets, afin de m'assurer que le NAS aille chercher les fichiers sur le disque. j'ai remarqué pour l'avoir redémarré souvent que ce qui est sur le volume de disque met un peu de temps pour être disponible. Utile, pas utile.... Mon DNS se charge avant le DHCP avec les liens symboliques dans son script de démarrage S09named, donc à priori, les données du volume sont déjà dispos pour le DHCP, qui heureusement se charge après le DNS.

Je suppose que pour ceux qui ne voudront pas s'énerver avec ce serveur en V4, ils doivent pouvoir ajouter une commande pour tuer le serveur DHCP du NAS et le recharger après le serveur Bind.

**

lease-file-name "/share/MD0_DATA/.qpkg/Optware/etc/dhcpd.leases";

pid-file-name "/var/run/dhcpd.pid";

"N'hésitez pas a nous donner les raisons de vos problèmes, pour que d'autres évite l'écueil ... par exemple si le probléme venait du "port truncking" (puisque vous parlez de bond0) et du fait que dhcpd se met par défaut à l'écoute de tous les eth et bond ... c'est une erreur bonne à connaître."

Le script DHCP.sh du nas fait un test des ports utilisables avant de configurer le DHCP, c'est ce qui m'a mis la puce à l'oreille!

Je crois que j'ai pour le moment un peu remédié à la suppression de mon précédent post qui était déjà bien long.

Je reviendrai plus tard, je l'espère avec un script de démarrage qui fonctionne... Mon serveur PXE ou Netboot attend un bon fonctionnement de mon serveur DHCP.....

Bonne journée et à plus tard.

Cdlt

Share this post


Link to post
Share on other sites

Bonjour,

Le serveur DHCP a fonctionné.

Je me demande encore ce qu'il se passe.

A ce propos, l'utilité du daemon_mgr, j'en ai trouvé une bonne: pendant que l'on fait des tests avec quelque chose qui ne remonte pas de logs comme ce serveur, utiliser le gestionnaire de process est bien pratique pour savoir ce qu'il se passe: il a passé sa matinée à me remonter des relaunch dhcpd.. Preuve que mon serveur ne fonctionne toujours pas aussi bien que je l'ai cru.

Bon WE.

PS si quelqu'un dispose d'un script générique et un dhcpd.conf un peu plus loquace que ceux fournis par le package ipkg, je prends! je crois que j'ai loupé quelque chose quelque part.

Share this post


Link to post
Share on other sites

Bonjour et bon début de semaine.

Je me permets de mettre sur ce forum le contenu de mon script de démarrage automatique du serveur DHCP 4.11P1 qui n'est pas lancé.

L'ensemble est une reprise du script du NAS. Les fichiers dhcpd.pid et dhcpd/leases sont déclarés dans le fichier de conf du DHCP, aussi je n'ai pas besoin de les rajouter ici.

La première partie définissant le port en écoute vient du script du NAS. Je force le chemin du fichier dhcpd.conf et la version de TCP/IP.

Je fais appel au daemon_mgr pour avoir d'éventuels remontées après le démarrage dans les journaux du système du NAS pour lancer le démon dhcpd et je suis même près à jongler avec les path des différents fichiers.

Le fichier de baux se trouve dans /opt/etc et le fichier PID est dans /var/run/

je l'avoue, je n'y connais pas grand chose en script et j'ai donc un peu de mal à comprendre ce qui ne fonctionne pas, J'aurais même l'impression qu'il n'est pas lu au démarrage....

Si je saisis dans une session ssh:/opt/etc/init.d/S56dhcp, il démarre....

Donc le voici:

#!/bin/sh

DEV=eth0

PROC_PATH=/opt/sbin

CONF_FILE=/opt/etc/dhcpd.conf

# See how we were called.

case "$1" in

start)

# Stop daemons

/bin/kill -HUP `/bin/pidof dhcpd`

# Start daemons

echo -n "Starting dhcpd: "

if [ `/sbin/getcfg Network "BONDING Support" -u -d FALSE` = TRUE ]; then

DEV=bond0

else

DEV=eth0

fi

/sbin/daemon_mgr dhcpd start "/opt/sbin/dhcpd -cf /opt/etc/dhcpd.conf -q -4 $DEV 2>/dev/null 1>/dev/null"

echo -n "dhcpd"

echo "."

touch /var/lock/subsys/dhcpd

# echo -n "ddns update"

# /etc/init.d/ddns_update.sh > /dev/null

# echo "."

;;

stop)

# Stop daemons.

echo -n "Shutting down dhcpd: "

/sbin/daemon_mgr dhcpd stop /opt/sbin/dhcpd

#kill -HUP `/bin/pidof dhcpd`

# local pid

pid=`/bin/pidof dhcpd`

if [ ! -z $pid ]; then

kill $pid

fi

echo -n "dhcpd"

echo "."

rm -f /var/lock/subsys/dhcpd

;;

restart)

$0 start

RETVAL=$?

;;

*)

echo "Usage: dhcpd { [start]|stop|[restart] }"

exit 1

esac

exit 0

Share this post


Link to post
Share on other sites

Bonjour,

Bonjour et bon début de semaine.

Je me permets de mettre sur ce forum le contenu de mon script de démarrage automatique du serveur DHCP 4.11P1 qui n'est pas lancé.

L'ensemble est une reprise du script du NAS. Les fichiers dhcpd.pid et dhcpd/leases sont déclarés dans le fichier de conf du DHCP, aussi je n'ai pas besoin de les rajouter ici.

La première partie définissant le port en écoute vient du script du NAS. Je force le chemin du fichier dhcpd.conf et la version de TCP/IP.

Je fais appel au daemon_mgr pour avoir d'éventuels remontées après le démarrage dans les journaux du système du NAS pour lancer le démon dhcpd et je suis même près à jongler avec les path des différents fichiers.

Le fichier de baux se trouve dans /opt/etc et le fichier PID est dans /var/run/

je l'avoue, je n'y connais pas grand chose en script et j'ai donc un peu de mal à comprendre ce qui ne fonctionne pas, J'aurais même l'impression qu'il n'est pas lu au démarrage....

Si je saisis dans une session ssh:/opt/etc/init.d/S56dhcp, il démarre....

Donc le voici:

#!/bin/sh

DEV=eth0

PROC_PATH=/opt/sbin

CONF_FILE=/opt/etc/dhcpd.conf

# See how we were called.

case "$1" in

start)

# Stop daemons

/bin/kill -HUP `/bin/pidof dhcpd`

# Start daemons

echo -n "Starting dhcpd: "

if [ `/sbin/getcfg Network "BONDING Support" -u -d FALSE` = TRUE ]; then

DEV=bond0

else

DEV=eth0

fi

/sbin/daemon_mgr dhcpd start "/opt/sbin/dhcpd -cf /opt/etc/dhcpd.conf -q -4 $DEV 2>/dev/null 1>/dev/null"

echo -n "dhcpd"

echo "."

touch /var/lock/subsys/dhcpd

# echo -n "ddns update"

# /etc/init.d/ddns_update.sh > /dev/null

# echo "."

;;

stop)

# Stop daemons.

echo -n "Shutting down dhcpd: "

/sbin/daemon_mgr dhcpd stop /opt/sbin/dhcpd

#kill -HUP `/bin/pidof dhcpd`

# local pid

pid=`/bin/pidof dhcpd`

if [ ! -z $pid ]; then

kill $pid

fi

echo -n "dhcpd"

echo "."

rm -f /var/lock/subsys/dhcpd

;;

restart)

$0 start

RETVAL=$?

;;

*)

echo "Usage: dhcpd { [start]|stop|[restart] }"

exit 1

esac

exit 0

Avant de savoir si une erreur s'est glissé dans votre script, il faut déjà être sur qu'il est lancé.

Les scripts sous /opt/etc/init.d NE SONT JAMAIS EXÉCUTÉS automatiquement par le boot di Qnap

ils ne le sont, QUE si une modification spécifique a été faites ....

soit : via autorun.sh avec attente de fin de boot ou d'être sur que Optware Ipkg a bien été lancé (deuxième phase du boot)

soit : par une modification du shell Optware-ipkg.sh qui est le script de lancement d'Optware (QPKG) exécuté au boot, il suffit d'y ajouter dans le start (et le stop) l'appel à un autre shell qui va lancer les scripts présent sous /opt/etc/init.d .... attention Ipkg ajoute des shells que vous ne voudrez pas voir automatiquement démarré... un liste précise sera plus sure qu'une boucle pour tous ... Attention de même, même si c'est très rare à jamais ... une mise à jour du shell d'origine (update) supprimera vos appels.

soit : créer des fake QPKG ... mais là c'est plus sioux ... je pense écrire un tutoriel la dessus dès que j'ai un moment.

Une fois sur, que votre shell est bien appelé, il faudra valider celui-ci, n'hésitez pas à ajouter des trace vers un log, en attendant que tout fonctionne,

Philippe.

Share this post


Link to post
Share on other sites

Bonjour Philippe,

Veux-tu bien être un poil plus clair s 'il te plait?

j'ai installé et configuré les packages ipkg Bind et DHCP. Les deux démarrent par une commande du type /opt/etc/init.d/<script> start mais seul le DNS est lancé au démarrage

Après lecture de ce wiki (http://wiki.qnap.com/wiki/Install_Optware_IPKG), j'ai compris que les scripts contenus dans /opt/etc/init.d ne sont lancés au démarrage qu'après avoir ajouté ces lignes dans le script Optware.sh":

" /bin/echo "Run Optware/ipkg /opt/etc/init.d/*"

source /etc/profile

# Start all init scripts in /opt/etc/init.d

# executing them in numerical order.

#

for i in /opt/etc/init.d/S??* ;do

# Ignore dangling symlinks (if any).

#[ ! -f "$i" ] && continue

case "$i" in

*.sh)

# Source shell script for speed.

(

trap - INT QUIT TSTP

set start

. $i

)

;;

*)

# No sh extension, so fork subprocess.

$i start

;;

esac

done "

Ce que j'ai fait: mon serveur DNS démarre d'ailleurs très bien sans intervention de ma part au démarrage de la machine. Je n'ai pas tout à fait compris le sens de ce "patch" mais il me semble que ça se traduit par:

pour tout élément contenu dans /opt/etc/init.d, il est lancé avec la commande "start", soit par exemple S09named start (démarrage de Bind) ou S56dhcp start (démarrage de DHCP).

Bon, je vais déjà ruser: je vais ajouter la création d'un petit fichier vide dans mon script pour voir s'il est lancé....

Retour dans quelques mn....

Encore merci

Fred

Share this post


Link to post
Share on other sites

J'ai rajouté la création d'un fichier dans /opt/etc par un touch toto dans mon script.

Il n'a pas été créé, voilà qui ne m'arrange pas si les scripts de démarrage des ipkg ne se lancent pas alors que j'ai mis au moins une semaine à trouver comment on pouvait tous les lancer...

Share this post


Link to post
Share on other sites

Problème résolu.

Pas très proprement mais la solution est fonctionnelle.

Je ne voulais pas toucher à la flash et pour ajouter un autorun.

J'ai finalement ajouté le démarrage de mes exécutables dans le script Optware.sh juste après les lignes:

/bin/echo "Enable Optware/ipkg"

# sym-link $QPKG_DIR to /opt

/bin/rm -rf /opt

/bin/ln -sf $QPKG_DIR /opt

Comme ça je m'assure de plusieurs faits:

_ Optware et IPKG sont utilisables à cet instant

_ La séquence de démarrage de mes exécutables est gérée: DNS, DHCP, NTP....

_ Pas de question à se poser quant à l'exécution des scripts du dossier /opt/etc/init.d; Certains semblaient bien se lancer, d'autres non..

Mais ça reste "sale" parce que si un exécutable plante, l'ensemble doit certainement planter! Peut-être qu'à mon retour de vacances

Share this post


Link to post
Share on other sites

bonjour, j'ai suivi un peu ce topic, j'ai dhcpd Internet Systems Consortium DHCP Server 4.1-ESV-R2.

et quand je le lance avec la commande /opt/etc/inid.d/S56dhcpd start il se lance mais apres il est killer.

/opt/etc/init.d/S56dhcp start

Internet Systems Consortium DHCP Server 4.1-ESV-R2

Copyright 2004-2011 Internet Systems Consortium.

All rights reserved.

For info, please visit https://www.isc.org/software/dhcp/

Wrote 0 deleted host decls to leases file.

Wrote 0 new dynamic host decls to leases file.

Wrote 0 leases to leases file.

Listening on LPF/bond0/00:08:9b:bf:57:1a/192.168.124.0/24

Sending on LPF/bond0/00:08:9b:bf:57:1a/192.168.124.0/24

Sending on Socket/fallback/fallback-net

et il n'y a rien dans les logs, jsute en web le message :

2011-06-03 15:30:49 System 127.0.0.1 localhost Stop process dhcpd.

voici mon dhcpd.conf qui est dans /opt/etc/dhcpd.conf:

ddns-update-style interim;

ignore client-updates;

subnet 192.168.124.0 netmask 255.255.255.0 {

# --- default gateway

option routers 192.168.124.254;

option subnet-mask 255.255.255.0;

option nis-domain "odes.local";

option domain-name "odes.local";

option domain-name-servers 192.168.200.41, 192.168.200.42;

# option netbios-name-servers 192.168.1.205;

# option time-offset -18000; # Eastern Standard Time

# option ntp-servers 192.168.1.1;

# option netbios-name-servers 192.168.1.1;

# --- Selects point-to-point node (default is hybrid). Don't change this unless

# -- you understand Netbios very well

# option netbios-node-type 2;

range dynamic-bootp 192.168.124.50 192.168.124.80;

default-lease-time 21600;

max-lease-time 43200;

}

host PKD17101 {

hardware ethernet 00:23:24:07:1d:40;

fixed-address 192.168.124.101;

}

host PKD17102 {

hardware ethernet 00:19:bb:4b:82:5d;

fixed-address 192.168.124.102;

}

host PKD17103 {

hardware ethernet 00:23:24:07:1d:20;

fixed-address 192.168.124.103;

}

host PKD17104 {

hardware ethernet 00:19:bb:4b:83:bb;

fixed-address 192.168.124.104;

}

host PKD17106 {

hardware ethernet 00:19:bb:4b:4b:47;

fixed-address 192.168.124.106;

}

host PKD17107 {

hardware ethernet 00:23:24:07:1d:76;

fixed-address 192.168.124.107;

}

host PKD17108 {

hardware ethernet 00:19:bb:4b:76:a6;

fixed-address 192.168.124.108;

}

host PKD17109 {

hardware ethernet 00:19:bb:4b:83:80;

fixed-address 192.168.124.109;

}

host PKD17501 {

hardware ethernet d8:d3:85:e9:9a:20;

fixed-address 192.168.124.91;

}

si vous avez une idee ? merci

Share this post


Link to post
Share on other sites

Bonjour,

Je suis l'auteur de ce topic et après avoir encore un peu bagarré avec ce serveur DHCP, j'ai fini par avoir une solution fonctionnelle qui se lance correctement tout seul et tient. Pour rappel, je ne suis pas un linuxien émérite donc....

Première chose que je vois, il y a au minimum deux à trois choses à déclarer dans ton fichier de conf:

1° l'interface sur laquelle doit écouter le serveur, je vois que ton serveur se lance sur un trunk donc comme moi, ajoute une ligne avec le contenu suivant: DHCPD_INTERFACES="bond0";

le 0 de Bond0 est un zéro....

2° la déclaration authoritative (autorisé): ajoute une ligne avec le contenu suivant: authoritative;

3° pas sûr que ce soit obligatoire mais il faut peut-être déclarer l'emplacement des fichiers liés au serveur (fichier de baux et fichier du process ID), ajoute deux lignes avec le contenu suivant:

lease-file-name "/opt/etc/dhcpd.leases";

pid-file-name "/opt/var/run/dhcpd.pid";

Il faut peut-être créer le dossier nommé run

Enfin, à force de bricolage et de Mises à jours divers, ma soluce qui avait permis de lancer automatiquement au démarrage le fichier init.d ne fonctionnait plus ou pas bien.

Par contre comme mon serveur bind démarrait bien et je me suis aperçu qu'un lien symbolique du fichier init.d de bind était présent dans le dossier /opt/etc/init.d donc j'en ai créé un pour celui du serveur DHCP nommé k92dhcpd (juste après k91named). A ce jour je n'ai pas cherché si c'était mes corrections qui avaient réglé ce problème ou ce lien symbolique mais ça tourne.

Enfin, un petit truc supplémentaire: toujours déclarer le chemin complet vers les fichiers et exécutables!

Vois déjà si cette solution fonctionne pour que ton serveur tienne.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×