Onderwerp: Elke nacht valt httpd service uit

Elke nacht valt de httpd service uit op mijn VPS. In DA komt de volgende melding als ik de service wil herstarten: 2<&1.

Als ik de server dan herstart is er niets meer aan de hand, tot de volgende nacht, dan valt de server net zo hard weer uit. Om 23:59 worden er backups gemaakt van WHMCS en dan tussen 00:15 en 02:00 valt de server uit. Ik heb alle logs bekeken die in DA te vinden zijn maar ik kom nergens een error tegen rond de tijd dat de service is gestopt.

Heeft iemand een idee wat er aan de hand is, of waar ik misschien logs kan vinden die wel wat meer vertellen?

Alvast bedankt

Is het nu HTTPd service die uitvalt of de gehele VPS/server? Je noemt de ene keer HTTPd service en andere keer server namelijk.

Verder misschien handig om te vermelden, hoe maak je backups wordt dit via HTTP gedaan met 1 php script of?

Tussen 00:15 en 02:00
Standaard rund de DirectAdmin tally om 00:10 en hierna herstart deze apache.
Vermoedelijk de bekende exim bug? wat geeft http terug als je op dit moment hiermee verbindt (telnet?)

@daveww, de service valt uit, server is typfout. Backups van WHMCS gaan met cron dmv PHP script, de normale backups worden om 06:00 gedaan (hebben hier dus niets mee te maken neem ik aan)

@Tim.Bracquez, In de logs staat het volgende over tally:

2009:03:16-00:10:xx: Tally 'username' Completed (voor alle users)
2009:03:16-00:10:22: Tally All Complete
2009:03:16-00:11:05: httpd restarted

De vraag over telnet snap ik niet geheel.. Ik maak alleen gebruik van DA en SCP protocol, hoe vraag ik de status op via Telnet?

welja ik bedoel gewoon wat deze terug geeft HTTP, of dit wel HTTP is of dat dit niet exim hiervoor gesprongen is. want dan moet je exim 'killen' en httpd een restart geven.

Maar kan je bijvoorbeeld nog op DirectAdmin of mail ontvangen ...?

Als je bijvoorbeeld telenet naar een service zal die normaal iets terug geven, stel telnet server.be 21 zal dit op een DA machine "220 FTP server ok" ofzo terug geven... telnet server.be 25 zal iets van een "220 server Exim..." terug geven.

Het moet ook 2>&1 zijn en niet 2<&1

Oorspronkelijk geplaatst door Tim.Bracquez

welja ik bedoel gewoon wat deze terug geeft HTTP, of dit wel HTTP is of dat dit niet exim hiervoor gesprongen is. want dan moet je exim 'killen' en httpd een restart geven.

Maar kan je bijvoorbeeld nog op DirectAdmin of mail ontvangen ...?

Als je bijvoorbeeld telenet naar een service zal die normaal iets terug geven, stel telnet server.be 21 zal dit op een DA machine "220 FTP server ok" ofzo terug geven... telnet server.be 25 zal iets van een "220 server Exim..." terug geven.

Ja e-mail blijft het wel doen, ook DirectAdmin blijft gewoon werken. DirectAdmin stuurt mailtjes dat de service niet gestart is. Met telnet port 80 openen geeft een error pagina van Apache "GET index.html is not supported".

Je moet eens kijken welke service poort 80 inneemt van zodra deze uitvalt.
Command hiervoor is:

netstat -tulpn| grep :80

Van zodra je dit weet kan je verder gaan uitzoeken waarom dat gebeurt.

Ik ben het nu in de gaten gaan houden, het gebeurt niet elke nacht. Het is nu enkele nachten niet gebeurt, maar een klein kwartier geleden wel weer.

@ServerBoost, als de service (en server) normaal draait krijg ik terug: 2248/httpd
Als de service gestopt is krijg ik dit terug: 5896/crond

Ik begrijp dat het iets met cronjobs te maken heeft, maar heeft iemand een idee wat er precies gebeurt?

Controleer even of er gekke crons draaien. Ook even voor de user APACHE
crontab -e -u apache

Mogelijk een cronjob die problemen geeft waardoor vervolgens Apache crashed.
Je kunt de cronjobs bekijken via

crontab -u <username> -l

Verder kun je ze natuurlijk ook via DA kijken onder User Level 'Cronjobs'.

Je kunt ook zodra je ziet dat crond de proces van HTTPd heeft overgenomen of er geen .php script via cron gedraaid wordt dmv "ps aux | grep php"

Alvast bedankt voor het meedenken! Zodra de boel er weer uit vliegt ga ik verder "op onderzoek uit". Ik laat het weten

Deze opdracht kun je meteen doen om te zien of er crons draaien die het kunnen veroorzaken. Daarvoor hoef je niet te wachten op een nieuwe outage

Je kunt het dan misschien voor zijn.

Bekijk ook even je logrotate configuratie. Ik heb onlangs op Red Hat iets gelijkaardig voor gehad.