php-fpm stopt regelmatig met werken

[AW_Bos]

Ik heb het idee dat php-fpm56 op mijn DirectAdmin VPS regelmatig lijkt te stoppen. Het geheugen lijkt normaal en de load lijkt vaak iets te stijgen,ook zonder hoge load lijkt het te gebeuren . Waarna php-fpm56 plotseling stopt met werken. De sites die via deze fpm-draaien zijn dan onbereikbaar en blijven laden totdat ik de services voor php-fpm56 opnieuw start. Andere sites op php-fpm70 lijken gewoon online te zijn.

Aanval? Ik zie niks bijzonders in de access_logs. Maar wel zie ik bij de processen in DirectAdmin dat er ongeveer 400 MB voor gebruikt wordt, terwijl er geen drukbezochte site op draait. Heeft iemand een idee waarom php-fpm regelmatig stopt? Ik kan mij niet indenken of een bepaald script daar verantwoordelijk voor is, ik heb de afgelopen dagen geen updates aan de server uitgevoerd.

Relevante software en hardware die ik gebruik
CentOS 7.0, Apache, DirectAdmin met meerdere PHP-versies als php-fpm

Wat ik al gevonden of geprobeerd heb

- Het verkeer naar mijn webserver lijkt ook niet te zijn toegenomen.
- Geen vreemde dingen in de access_log van mijn webserver
- Ik heb ook al in /var/logs gekeken naar de php-fpm56.log maar die lijkt niet te worden gebruikt.
- Inmiddels heb ik de hele VPS-server even gerestart met de hoop dat het nu rustig blijft, maar na een klein uur was het weer raak..
- Gekeken naar vreemde processen, maar het lijkt er niet op
- Ook geen vreemde access logs in ssh.

Waar kan ik verder naar kijken? Omdat de laod prima is, en het geheugen ook prima, denk ik dat er weinig mis is op de VPS-master server van mijn hosting. Maar opvallend was dat er voorheen wel wat hogere load was waarbij de boel eruit klapte.

[ Voor 5% gewijzigd door AW_Bos op 17-03-2019 00:10 ]

[RobIII]

AW_Bos schreef op zaterdag 16 maart 2019 @ 23:26:
Waar kan ik verder naar kijken?

Dit is niet het antwoord op je vraag dat je wil horen (en ik weet te weinig van PHP om er echt antwoord op te kunnen geven) maar waarom heb je überhaupt nog een EOL versie draaien? Ik geef het maar als heads-up... misschien was je je er niet van bewust?

[ Voor 27% gewijzigd door RobIII op 16-03-2019 23:33 ]

[AW_Bos]

@RobIII Dat duurt gelukkig niet heel lang meer, en ben er héél goed van bewust .
Een van mijn sites draait dat nog, maar dat is over een maand of wat echt over naar PHP 7.2...

[RobIII]

AW_Bos schreef op zaterdag 16 maart 2019 @ 23:32:
@RobIII Dat duurt gelukkig niet heel lang meer, en ben er héél goed van bewust

Just checking

[Hero of Time]

Welke webserver draait er bij? Is dat Apache of Nginx? Als je Apache gebruikt, maak je dan gebruik van modphp, of proxy je het net zoals met Nginx wordt gedaan naar php-fpm?

Ik zou sowieso even kijken of je andere PHP zaken naar hun eigen log gaan. Zou zomaar kunnen dat ze naar syslog gaan.

Daarnaast zou ik persoonlijk de server niet via DirectAdmin beheren. We hebben op kantoor helaas een machine die dit draait. En we komen er ook niet zo snel vanaf. Voor een doorgewinterde Linux beheerder is DA voor mij een grote zwarte doos.

Als je bang bent voor aanvallen, installeer dan fail2ban en richt deze in. DA zegt dat het ook brute-force aanvallen tegen kan houden op een vergelijkbare manier, maar het vereist wat meer configuratie en custom scripts. De opzet bij ons werkt niet omdat het nooit de bijbehorende iptables chain maakt. Een bug die je met een custom oplossing moet fixen. De functionaliteit, van wat ik heb bekeken, is ook niet zo uitgebreid als F2B.

[AW_Bos]

Draait enkel op Apache, en geen Nginx, ook geen proxy.
Momenteel zit er al LFD en CSF op, en ja... ik heb liever Direct Admin
En nee, ik ben geen doorgewinterde Linux-man Ik weet er wel het nodige van af, maar tot hier wordt voor mij lastig te troubleshooten.

Ik heb al wat tijdelijks geprobeerd met:
emergency_restart_threshold = 10
emergency_restart_interval = 20s

maar dan weigert fpm meteen op te starten

update
Vannacht is hij stabiel gebleven. Geen uitval...
Ik vermoed een hoop bezoekers wat zeker niet excessief aantal is, of een aanval...

Maar kan dat enkel een enkele php-fpm omvertrekken i.p.v. heel apache? Valt fpm te tweaken?

[ Voor 29% gewijzigd door AW_Bos op 17-03-2019 09:45 ]

[Hero of Time]

Er zijn andere tools dan DA om je machine mee te beheren. Allemaal hebben ze wel wat uiteraard.

Maar je moet eerst achterhalen waarom fpm onderuit gaat. Dit kan door geheugenproblemen komen, maar ook door problemen in je code dat het uitvoert. Kijk bijvoorbeeld naar https://stackoverflow.com...doesnt-write-to-error-log of https://serverfault.com/q...s-written-in-php5-fpm-log om logging aan de praat te krijgen.

[AW_Bos]

Geheugenprobleem lijkt mij sterk. Dat is pas nog geupgraded. Vanmiddag als ik thuis ben ga ik even kijken naar de fpm-log.

Maar volgens Google Analytics wordt een bepaalde pagina veel bekeken, zonder refferals.

Mogelijk misschien een mysql table-lock, zegt een kennis. Maar kan dit idd fpm omverschoppen? Ik zou dan eerder een mysql error verwachten?

[ Voor 28% gewijzigd door AW_Bos op 17-03-2019 13:09 ]

[Hero of Time]

Al heb je 4 TB geheugen, dan nog kan je php-fpm tegen geheugenproblemen aanlopen. Het ligt eraan hoeveel het mag gebruiken. Als dat nog de standaard 128 MB is en het heeft 192 MB nodig, dan gaat het alsnog op z'n plaat.

[AW_Bos]

Waar kan ik dat vinden? Fpm config?

[Hero of Time]

Blijkbaar heb je de links die ik postte over de log files niet gelezen, want daar wordt de locatie van de configuratiebestanden ook genoemd. Alles staat in een logische structuur onder /etc.

[AW_Bos]

Bij DirectAdmin is dat soms anders, maar ik snap wat je bedoelt. Nu kijken welke setting dat is.

[ Voor 49% gewijzigd door AW_Bos op 17-03-2019 14:36 ]

[Hero of Time]

En dat is dus ook de reden waarom ik een afkeer heb jegens DA. De standaard die je leert, gaat daar niet altijd op en dat is erg frustrerend als er dus een issue is. Zit je het verkeerde te bewerken, terwijl je vloekend zoekt naar de juiste plek.

[AW_Bos]

Ik zal even zoeken in de fpm-config. Of doel je op PHP's memory limit?

[Hero of Time]

Het geheugen limiet voor fpm. Dat staat in de fpm config, niet in php.ini.

[AW_Bos]

Ah, ik ga op onderzoek uit.

[Hero of Time]

Let ook op hoe apache fpm aanroept. Daar kan ook nog geheugen opties meegegeven worden.

[BlackMonkey]

Is je custombuild up to date? Je zou php met modules even opnieuw kunnen builden met custombuild. Mijn ervaring met DA is dat er soms wat corrupt raakt maar dat een rebuild dit vaak wel fixt (al is het een brakke oplossing natuurlijk).

[AW_Bos]

@BlackMonkey Ik kan het proberen. Maar er werd een een bepaalde URL van mijn site veel aangeroepen. Geen Wordpress of andere 3rd party iets, maar een bepaalde pagina. Inmiddels is de massale bezoekersstroom gestopt.

Maar ik zie sinds een update van Direct Admin nog een paar andere dingen op de server:
Een PHP-file met header('HTTP/1.0 404 Not Found'); triggert nu een Apache melding met 404. Het script lijkt dus te stoppen in dit geval?
Dat heb ik nooit eerder meegemaakt .

Maar ik ga morgen even kijken hoe ik php-fpm kan tunen. Dat lijkt me even het belangrijkst.

Zo draait het tijden prima. En zo heb je vage dingen

[ Voor 49% gewijzigd door AW_Bos op 17-03-2019 20:26 ]

[AW_Bos]

Vandaag weer enkele malen een uitval gehad, en ontdekt dat dit een mogelijke boosdoener leek te zijn.

[Sun Mar 17 19:08:22.222716 2019] [negotiation:error] [pid 10722:tid 140590142437120] [client 80.101.***.***:54299] AH00687: Negotiation: discovered file(s) matching request: /home/my_username/domains/site.com/public_html/http_status_code (None could be negotiated)., referer: http://www.site.com/news/7668

[Sun Mar 17 19:08:22.230778 2019] [core:error] [pid 10722:tid 140590089987840] [client 80.101.**.**:54298] AH00124: Request exceeded the limit of 10 internal redirects due to probable configuration error. Use 'LimitInternalRecursion' to increase the limit if necessary. Use 'LogLevel debug' to get a backtrace., referer: http://www.site.com/news/7668

Dit ontstond dus na een update van Directadmin ( ), en ik vermoed dat elke request dus een loop maakte naar de error-afhandeling van de site. Nu dit is getakceld met een nieuwe versie van Direct Admin werkt het prima. Weinig slurpend geheugen meer op de fpm.

Opvallend detail:
Hierdoor werden alle headers in PHP doorgesluisd naar de errorpages van Apache zelf, wat soms een raar resultaat geeft op een site, als je op een eigen error-pagina een 404-header meegeeft.

Ik blijf erbij dat een eigen LAMP-setup voor een site beter is, maar ik heb DA ooit aangevraagd omdat ik er wat andere mensen op wou kunnen hosten die zelf wat kunnen beheren, en omdat mijn eigen hosting dit ondersteunt en direct op kon leveren. Maar ik zie nu wel nadelen, terwijl ik zeker weet dat het anders heel makkelijk te tackelen was.

[ Voor 11% gewijzigd door AW_Bos op 18-03-2019 15:40 ]