DNS server start niet automatisch op

[Briolet]

Na de update naar DSM 6.1.2-15132 had ik weer overal reclame op sites, die er normaal niet was. Het duurde even, maar al snel keek ik naar de dns server (Met adblock).

Op de een of andere manier wilde de server niet opstarten omdat poort 53 al in gebruik was. (die gebruikt hij zelf). Bij de vorige update gebeurde dit voor het eerst.  Nu denk ik dat de oorzaak niet de update zelf is, maar het herstarten van de nas.

Handmatig aanzetten gaat probleemloos. wel een punt om naar te kijken voor anderen.

[Briolet]

Dit probleem speelt bij mij nog steeds. Niet alleen bij een update maar bij de helft van alle reboots van de nas. Dus ook als ik reboot zonder update.

Na een reboot werkt de DNS server soms niet. Als ik naar Package center ga, zie ik dat het pakket gestopt is. Als ik hem dan start, krijg ik de foutmelding: "Port 53 is used by other process, please make sure port 53 is avaliable on all interface before start DNS Server", maar de DNS server werkt desondanks weer.

Ik heb eens naar het "start-stop-status" script gekeken dat elk package heeft. Daarin vind ik de functie die deze error genereert:

Code: [Selecteer]

DNS_PORT_CHECK()
{
PORT_STATUS=`netstat -lntu | grep LISTEN | awk '{print $4}' | grep ':53$'`
# before start named, use netstat to check if port 53 is listen by other process.
if [ "x${PORT_STATUS}" != "x" ]; then
/bin/echo "Port 53 is used by other process, please make sure port 53 is avaliable on all interface before start DNS Server" > ${SYNOPKG_TEMP_LOGFILE}
exit 1
fi
}

Wat opvalt is dat het script een "exit" doet na deze logging. De actie hierna is pas het proberen om het pakket te starten. Het kan dus niet zijn dat deze foutmelding optreed en het pakket desondanks gestart wordt. Blijkbaar zit er een bug in PackageCenter dat hij de temp logfile niet wist voordat hij start. Volgens mij krijg ik nu de error te zien die tijdens de reboot gelogd is en is er helemaal geen error als ik hem start via Package Center.

In elk geval treed die fout op nog voordat er een poging is om het pakket te starten. Dus kun het niet aan liggen aan de grote datafiles door gebruik als adblokker.

PS: heeft iemand enig idee waar ik de "SYNOPKG_TEMP_LOGFILE" kan vinden? Deze variabele wordt in elk geval niet in het script zelf gedefinieerd. Dat doet blijkbaar een bovenliggend script.

[Ben(V)]

Als ik dat stukje script lees dan doet hij een netstat -lntu en kijkt in het resultaat of poort 53 bezet is.
Dat leest hij niet uit de temp logfile., dus wat daar in zou staan heeft geen invloed.

Die environment variable SYNOPKG_TEMP_LOGFILE bestaat alleen gedurende de installatie van een package.
De resultaten daarvan worden doorgesluisd naar de package log file.

De package center logfile logfile is hier te vinden:
/var/log/synopkg.log

Specifiek logs van de DNS installatie kun je hier vinden:
/var/packages/DNSServer/target

EDIT:
Wat ik denk dat er aan de hand is, is dat het opstarten soms net te langzaam gaat en dat de pidfile niet snel genoeg aangemaakt wordt.
Het package centrum kijk naar die pidfile in de check status en als die er niet is stopt hij het package weer.
Je zou dat kunnen uittest door even in de een sleep in te bouwen voor regel 188 zijnde:
COUNT_DNS=`/bin/ps ax | grep -c named`

[Briolet]

Die logfile heb ik gevonden. Maar dat is niet de tijdelijke logfile waar deze fout naar toe geschreven wordt.

Als ik in die logfile kijk, vallen me nog meer fouten op. Ik zie b.v. steeds terugkomen:

Code: [Selecteer]

mkdir: cannot create directory '/var/packages/DNSServer/target/named/etc/zone/slave': File exists
mkdir: cannot create directory '/var/packages/DNSServer/target/named/etc/zone/data': File exists
mkdir: cannot create directory '/var/packages/DNSServer/target/named/dev': File exists
mkdir: cannot create directory '/var/packages/DNSServer/target/named/tmp': File exists

Kijk ik in het start-stop-status script, dan is de code:

Code: [Selecteer]

InitDirectory()
{
if [ ! -f "${ChrootDir}/var/run/named" ]; then
mkdir -p ${ChrootDir}/var/run/named
fi
if [ ! -f "${ChrootDir}/var/log" ]; then
mkdir -p ${ChrootDir}/var/log
fi
if [ ! -d "${ChrootDir}/etc/key" ]; then
mkdir -p ${ChrootDir}/etc/key
fi
if [ ! -f "${ChrootDir}/etc/zone/master" ]; then
mkdir -p ${ChrootDir}/etc/zone/master
fi
if [ ! -f "${ChrootDir}/etc/zone/slave" ]; then
mkdir ${ChrootDir}/etc/zone/slave
fi
if [ ! -f "${ChrootDir}/etc/zone/data" ]; then
mkdir ${ChrootDir}/etc/zone/data
fi
if [ ! -f "${ChrootDir}/dev" ]; then
mkdir ${ChrootDir}/dev
fi
if [ ! -f "${ChrootDir}/tmp" ]; then
mkdir ${ChrootDir}/tmp
fi
}
Oftewel: bij deze folders kijken ze of de naam als file bestaat en dan proberen ze een folder aan te maken. Alleen bij de "key" directory controleren ze terecht of de folder al bestaat. (d en f parameter)
Er wordt mij meer ten onrechte op file i.p.v. folder gecontroleerd, maar daar wordt de 'p' parameter meegegeven bij 'mkdir' zodat hij geen error geeft bij een bestaande folder.

Kijken ze bij Synology nooit in de logbestanden om dan de oorzaak van foutmeldingen op te sporen. Als mij dat als amateur opvalt, hadden ze die fout bij Synology toch allang moeten zien?

Als ik dat stukje script lees dan doet hij een netstat -lntu en kijkt in het resultaat of poort 53 bezet is.
Dat leest hij niet uit de temp logfile., dus wat daar in zou staan heeft geen invloed.

Misschien verkeerd begrepen. Ik bedoelde dat hij schrijft naar die temp logfile. Ik had wel gezien dat die netstat kijkt op poort 53 bezet is. Na opstarten staat daar:

Code: [Selecteer]

netstat -lntu | grep LISTEN | awk '{print $4}' | grep ':53$'
10.0.6.1:53
10.0.4.1:53
10.0.1.30:53
127.0.0.1:53
:::53
Die check kijkt of hij op dat moment helemaal leeg terug komt. Dat is blijkbaar bij de helft van mijn reboots niet zo. Misschien moet ik dat script aanpassen zodat het die variabele ook naar een log wegschrijft zodat er meer duidelijkheid komt waar het probleem zit. NB mijn lan zit op 10.0.1.x
10.0.6.x is open vpn en 1.0.4.x ik mijn wifi dongle.

[Ben(V)]

Misschien mijn laatste edit niet gelezen?

Dat probleem ben ik namelijk bij mijn eigen package van autosub ook eens tegengekomen.
De check status kijkt te vroeg naar de pidfile die er nog niet is, omdat het opstarten wat lang duurde.
Komt vooral voor of wat kleiner Nassen en/of veel gelijktijdig opstartende packages.

Dat verklaart namelijk ook dat het soms wel en soms niet goed gaat en dat handmatig opstarten meestal wel goed gaat.

[Briolet]

Nee, niet gelezen. Maar het probleem is echt die poort. De 'status' check loopt goed. Het gaat mis in het 'start' deel. Ik heb het "start-stop-status" script aangepast en de waarde van die variabele, die leeg moet zijn om door te kunnen gaan, laten wegschrijven. Vervolgens heb ik een reboot gedaan.

DNS server was niet opgestart en die variabele had als inhoud:

Code: [Selecteer]

0.0.0.0:53 :::53Dus niet leeg, maar ook geen specifiek IPv4 en IPv6 adres.

Vervolgens in de /tmp directory gezocht en daar vond ik de logfile die ik zocht. "/tmp/synopkgmgr.log-DNSServer". Met als inhoud de foutmelding:

Code: [Selecteer]

$ cat /tmp/synopkgmgr.log-DNSServer
Port 53 is used by other process, please make sure port 53 is avaliable on all interface before start DNS Server
Het is dus zoals ik verwachtte. Als ik het pakket vervolgens met de hand opstart, start het probleemloos op. Maar Package Center ziet dat er ook een logfile is en laat die zien. Maar dit is mosterd na de maaktijd om een oude fout te tonen. Dit verwart alleen maar omdat het opstarten nu juist goed gaat. Blijkbaar wordt dat logbestand alleen gewist nadat het getoond is en niet voordat je een pakket probeert handmatig te starten.

[Briolet]

Voor de aardigheid heb ik een regel toegevoegd aan dat logbestand en toen de DNS server weer gestart. Ik krijg nu de volgende foutmelding:



Hij laat dus inderdaad een foutmelding zien die helemaal niet meer van toepassing is. Lekker verwarrend.

Het echte probleem van niet starten is natuurlijk nog steeds niet opgelost.

[Ben(V)]

Het echte probleem is vermoedelijk toch een timing probleem.
Als je namelijk die DNS server met de hand stopt en dan het volgende commando ingeeft:

Code: (shell) [Selecteer]

netstat -lntu | grep LISTEN | awk '{print $4}' | grep ':53$'Is er geen 0.0.0.0:53 en bij mijn weten worden bij een normale shutdown alle packages regulier gestopt.

Die 0.0.0.0:53 ontstaat dus tijdens het starten van de DNS server.

[Pippin]

Vraag mij af of het adblock script, indien in gebruik, de boel zodanig vertraagt zodat er een time-out plaatsvindt...

[Briolet]

Ik zat eerst ook aan adblock te denken, maar die check waar hij op vast loopt, gebeurd voordat hij begint met het opstarten van de DNS server. Dus dat de DNS server er misschien lang over doet om op te starten, mag geen reden zijn.

Zoals Ben schrijft, is het ergens een timing probleem. Ook al omdat het niet altijd mis gaat Als het aan het adblok script lag, zou je dit ook bij handmatig starten zien.

[Ben(V)]

Ik zou gewoon net voor hij die poort check doet een sleep van 2 seconden invoegen, om te kijken of het dan nog steeds optreed.

[Briolet]

Helpt niet. Ik heb er een 5 sec sleep voor gezet.

Als je direct na de reboot inlogt en naar Package Center gaat, zie je dat de packages nog bezig zijn om op te starten. Ik was eerst lekker hoopvol:



Maar dat 'Starten…' veranderde plots in "Stoppen…" en tenslotte in "Gestopt". 

[Briolet]

De problemen begonnen met DSM 6.1. Ik heb nu ook mijn hoofdnas naar DSM 6.2 geupgrade. Na de restart draaide de DNS server nu wel. Nu het installeren van de update 2 en opnieuw restarten, werkte de DNS server ook weer.

Ik ben benieuwd of dit toeval is. Bij DSM 6.1 ging het ook wel eens goed. En als dit een gevonden bug was, zouden ze die ook in de laatste 6.1 patch verholpen zijn.

Wel iets vreemds met factor 2 autenticatie. Sinds 6.2 moet dit ook voor een ssh inlog gelden. Op mijn 212j met DSM 6.2 is dat ook zo, maar op mijn 415+ kon ik zo inloggen.
(Of zou ik het eerst uit en dan weer aan moeten zetten zodat het voor SSH actief wordt?)

[Briolet]

Nu doet mijn Wifi het niet. (Wel verbinding maar geen autenticatie)  Via kabel op de nas ingelogd en nu bleek de radius server niet gestart te zijn bij de laatste reboot:



Ook een probleem met een niet beschikbare poort. Ook hier was de server wel weer te starten via Package Center. Nu maar hopen dat dit eenmalig was door het extra werk kort na een upgrade.