Bekijk Volledige Versie : Directadmin/server/mail -tijd kloppen, cronjob word 6 uur te laat uitgevoerd.
sanderb123
25/12/11, 20:05
Hallo,
Ik heb een VPS (Debian 6 x64) waarop Directadmin opstaat geinstalleerd (laatste versie).
Nu kwam ik er laatst achter dat de tijd waarop de mailtjes aankwamen en werden verzonden niet klopte, maar de server tijd wel. Ik heb toen de tijd opneiuw ingesteld, en toen was dat probleem verholpen/
Alleen nu worden de cronjobs die in DirectAdmin staan ingesteld te laat uitgevoerd (ongeveer 6 uur te laat) weet iemand waar dit zit? de servertijd, mailtijd en tijd binnen directadmin (via procesmonitor) kloppen wel.
Wie kan mij helpen? Alvast bedankt!
Met vriendelijke groet,
Sander
patrickekkel
25/12/11, 20:35
Heb je de tijdzone wel goed staan ??
Wat is de output van de command "date"
sanderb123
25/12/11, 20:46
als ik het commando date invoer krijg ik het volgende:
Sun Dec 25 20:45:24 CET 2011
patrickekkel
25/12/11, 20:55
Oké dat zit op de goede tijdzone
Wat is de virtualisatie techniek waar je op draait?
Het kan zijn dat de tijd op de vps node goed gezet moet worden
sanderb123
25/12/11, 20:58
De VPS draaid bij PC Extreme. ik heb echter geen idee welke techniek hun gebruiken.
Wat ik wel gek vind, eerst werden cronjobs wel op tijd uitgevoerd en stond de servertijd ook goed, toen heb ik dit aangepast (opnieuw de tijd/datum ingesteld) omdat de mailtijd niet klopte, dit klopt nu dus wel.... maar de cronjobs tijd klopt dus niet..
systemdeveloper
25/12/11, 21:10
De cron is gebaseerd op de hardware tijd, niet op de systemtijd. Waarschijnlijk staat de hardware tijd van de server gewoon niet goed.
sanderb123
25/12/11, 21:11
bij het uitvoeren van hwclock krijg ik:
Sun 25 Dec 2011 9:10:43 PM CET -0.819972 seconds
klopt dus wel volgens mij
systemdeveloper
25/12/11, 21:21
bij het uitvoeren van hwclock krijg ik:
Sun 25 Dec 2011 9:10:43 PM CET -0.819972 seconds
klopt dus wel volgens mij
Als je op een vps zit hoeft dat niet te kloppen aangezien je hardware gevirtualiseerd is.
sanderb123
25/12/11, 21:22
maar hoe kan het dat dit eerder wel goed ging, totdat ik de tijd opnieuw heb ingesteld voor de mail?
systemdeveloper
25/12/11, 21:27
maar hoe kan het dat dit eerder wel goed ging, totdat ik de tijd opnieuw heb ingesteld voor de mail?
Geen flauw idee, ik beheer je vps niet en heb het niet in elkaar geknutseld.
Maar je hebt nu eenmaal niet gek veel opties:
- node hardware tijd niet correct
- node tz niet correct
- tijd vps niet goed
- tz vps niet goed
- verkeerde tz in script
Wat je kunt doen is even een cron zetten die alleen een 'echo date' doet en in je cronmail eens kijken wat dat is. Als user inloggen of als cron zijn ook nog 2 verschillende dingen tenslotte.
sanderb123
25/12/11, 21:42
als ik een cronjob invoer zoals je zegt krijg ik keurig mailtjes met:
Sun Dec 25 21:41:01 CET 2011
Hij voert hem nu elke minuut uit, dit klopt dus wel....
systemdeveloper
25/12/11, 21:48
als ik een cronjob invoer zoals je zegt krijg ik keurig mailtjes met:
Sun Dec 25 21:41:01 CET 2011
Hij voert hem nu elke minuut uit, dit klopt dus wel....
Maar als je de cron op '* 21' zet (elke minuut, dit uur) dan krijg je dus niks?
sanderb123
25/12/11, 21:51
neh, als ik bijvoorbeeld 49 * instel gat het wel goed dus de minuten staan wel goed.
bij * 21 gaat het niet goed, de uren lopen dus niet goed, maar de minuten wel...
systemdeveloper
25/12/11, 22:06
Nog iets in de cron logs rond die tijd?
sanderb123
25/12/11, 22:15
hele domme vraag misschien maar hoe kan ik deze cron log openen?
ik kan hem niet vinden via de log viewer functie van DirectAdmin, of moet dit op de VPS zelf?
Heb je de crond service wel herstart na je aanpassingen, en alle logs zijn terug te vinden in /var/log/.
sanderb123
25/12/11, 22:32
aaah dat meen je niet! goh wat stom! na het herstarten van de service klopt het. nu word hij ook bij * 22 uitegevoerd.
Heel erg bedankt!
Gr,
Sander
Graag gedaan, laat dit een les zijn voor in de toekomst om je services te reloaden/restarten na aanpassingen ;) de meeste services draaien namelijk vanuit memory dus zonder herstart blijven ze gebruiken wat in het memory/cache zit.
sanderb123
25/12/11, 22:43
inderdaad, heel stom dat ik hier niet aangedacht heb...
maar in ieder geval bedankt allemaal!:lovewht:
Graag gedaan, laat dit een les zijn voor in de toekomst om je services te reloaden/restarten na aanpassingen ;) de meeste services draaien namelijk vanuit memory dus zonder herstart blijven ze gebruiken wat in het memory/cache zit.
Klopt, net als /etc/resolve.conf. Ooit ook tegen aangelopen. Pas na een restart van de service (het ging op Apache) werd /etc/resolv.conf opnieuw ingelezen.