[CentOS] Apache reageert niet op willekeurige momenten

[Verwijderd]

Ik heb een vaag probleem op mijn VPS waarop ik productie websites draai. Op willekeurige momenten (gemiddeld 1 tot 3 keer per dag) reageert mijn VPS niet via http en https.

Het gaat om een BladeVPS van TransIP. Ik draai CentOS 6.8 met DirectAdmin 1.50.1, Apache 2.4.25, etc.

Tijdens de momenten dat de websites niet reageren (dit duurt vaak maar 1 minuut) kan ik de server wel bereiken via SSH, FTP, en het DirectAdmin controle panel..

Wat ik tot nu toe heb geprobeerd:
- Apache geupdate naar laatste versie
- LogLevel van Apache op 'debug' gezet

In de errorlog van Apache staat 0 relevants.

Om ongeveer 15:42:05 gingen de websites weer offline voor ~ 60 seconde (http time out).

code:

[Thu Feb 09 15:24:56.449560 2017] [proxy_hcheck:debug] [pid 6121:tid 139822197200640] mod_proxy_hcheck.c(873): AH03313: apr_thread_pool_create() with 16 threads succeeded
[Thu Feb 09 15:43:12.623887 2017] [watchdog:debug] [pid 7929:tid 139822202595264] mod_watchdog.c(586): AH02981: Watchdog: Created worker thread (_proxy_hcheck_).

Omdat ik al sinds 30 januari met dit probleem bezig ben, had ik in mijn browser /server-status/ open staan op autorefresh zodat ik de laatste 'status' kon bekijken vlak voordat het probleem optrad.

code:

Current Time: Thursday, 09-Feb-2017 15:42:03 CET
Restart Time: Thursday, 09-Feb-2017 02:12:04 CET
Parent Server Config. Generation: 1
Parent Server MPM Generation: 0
Server uptime: 13 hours 29 minutes 59 seconds
Server load: 0.17 0.26 0.27
Total accesses: 99945 - Total Traffic: 969.3 MB
CPU Usage: u186.6 s60.31 cu0 cs0 - .508% CPU load
2.06 requests/sec - 20.4 kB/second - 9.9 kB/request
4 requests currently being processed, 60 idle workers

Ongeveer een minuut later kon ik de server weer bereiken:

code:

Current Time: Thursday, 09-Feb-2017 15:43:23 CET
Restart Time: Thursday, 09-Feb-2017 02:12:04 CET
Parent Server Config. Generation: 1
Parent Server MPM Generation: 0
Server uptime: 13 hours 31 minutes 19 seconds
Server load: 0.15 0.23 0.26
Total accesses: 100350 - Total Traffic: 972.5 MB
CPU Usage: u187.36 s60.47 cu0 cs0 - .509% CPU load
2.06 requests/sec - 20.5 kB/second - 9.9 kB/request
12 requests currently being processed, 116 idle workers

Het lijkt dus niet op een Apache crash of dergelijks.In /var/log/messages staan ook geen acties van de firewall.
Wie heeft er een idee waar ik dit moet zoeken en hoe ik dit kan oplossen? Omdat er bijna 24/7 op de websites gewerkt word begint het nu wel irritant te worden voor de gebruikers.

[Hero of Time]

Als je bij kan houden wanneer het gebeurt, vraag het TransIP. Lijkt mij de eerste stap, want voor hetzelfde geld zit je je rot te zoeken terwijl zij een netwerk hiccup hebben.

[Verwijderd]

Een netwerk hickup? Zou dat kunnen? ping -t laat geen enkele timeout ziet terwijl het gebeurd.
Ik heb hetzelfde bericht ook eens uitgezet bij de support afdeling.

[ Voor 26% gewijzigd door Verwijderd op 09-02-2017 16:30 ]

[Kees]

Zo te zien deed hij wel bijna 405 requests tussen die twee /server-status refreshes in. Daarnaast is het aantal workers gestegen van 64 naar 128 dus ik neem aan dat je mpm_worker gebruikt die een nieuwe pool opschoot omdat de vorige helemaal vol zat en dat je daardoor even niet bij je server kon komen totdat de nieuwe pool aangemaakt werd, waarop de oude requests ook ineens weg waren.

Zie je requests in de accesslogs?
Log je timing informatie in de accesslogs zodat je kan zien hoelang een request duurde?

Voorbeeld van een duidelijkere accesslog:

LogFormat "\"Timestamp\":%{%s}t,\"RemoteAddr\":\"%a\",\"LocalIP\":\"%A\",\"Method\":\"%m\",\"BytesSent\":%B,\"TimeTaken\":%D,\"Status\":%>s,\"ServerPort\":%p,\"FileName\":\"%f\",\"ServerPid\":%P,\"QueryString\":\"%q\",\"UrlPath\":\"%U\",\"Request\":\"%r\",\"HostHeader\":\"%{Host}i\",\"Referer\":\"%{Referer}i\",\"UserAgent\":\"%{User-agent}i\",\"Forwarded\":\"%{Forwarded}i\", \"LogId\":\"%L\"}" jsonlog
CustomLog "/var/log/apache2/access-json.log" jsonlog

[ Voor 7% gewijzigd door Kees op 09-02-2017 16:36 ]

[Verwijderd]

Er staan vanaf 15:42:12 tot 15:43:11 geen entries in de access logs. Heeft uitgebreidde logging dan wel nut? Het verkeer lijkt in die minuut niet bij apache te komen.

Reactie TransIP:

Ik kan je aangeven dat er geen netwerkproblemen zichtbaar of gemeld zijn en dat wij de kans vrij klein achten dat dat de oorzaak hiervan is. Wij zouden dan meer meldingen moeten krijgen (en de monitoring zou dit rapporteren) en daarnaast zou dat niet slechts op poort 80 / 443 zijn, maar op alle poorten.

Omdat onze VPS-diensten volledig selfmanaged zijn ben ik bang dat wij hierin weinig kunnen betekenen (ik heb echt geen flauw idee wat dit zou kunnen zijn), maar ik ben bereid als uitzondering dit voor te leggen aan een collega van techniek. Ik kan echter absoluut geen garanties geven dat deze een oplossing hiervoor heeft.

Zodra ik meer informatie voor je heb dan zal ik dat zo spoedig mogelijk laten weten en ik wens je verder nog een fijne dag.

Ik heb inmiddels de timing informatie toegevoegd aan mijn LogFormat.

[ Voor 73% gewijzigd door Verwijderd op 09-02-2017 23:11 . Reden: Reactie TransIP toegevoegd ]

[Kees]

Tja, of verkeer wel of niet bij apache kan komen zul je moeten testen tijdens zo'n downtime. Ik zelf zou het debuggen met de volgende stappen:

- als eerste, zet tcpdump aan zodat je alles logged wat jij naar de server stuurt (op poort 80)
- kan ik connecten naar poort 80? (nmap -sT -p 80 domein.nl)
- kan ik een eenvoudige request doen? (wget http://domein.nl/robots.txt)
- op de server zelf; wat zeggen ps auxfww, top, dmesg, en andere logs?
- strace -ff -ttt -o apache.trace -p $pid-van-apache

Maar hier komt wel vrij veel informatie uit waar je niet altijd even makkelijk een oorzaak uit kan halen

[Hero of Time]

Ik zou daar een tcptraceroute aan toevoegen, want nmap -p 80 doet alleen connecten, die laat niet de tussenliggende hops zien mocht er ergens wat gedropt worden.

[Verwijderd]

Ik werk zelf op een windows bak, dus wat zijn daar dan de juiste tools voor haha.
Het lastige is, ik zal dan snel moeten schakelen. Ik heb het vaak pas na een aantal seconde door en dus iets van 30 seconde de tijd om alle tests uit te voeren.

Ik merk het ook alleen maar op de momenten dat ik zelf werk, monitoring gaat niet 'af' omdat er geen http timeout optreed.

Edit:
Heb een tcptraceroute voor windows gevonden, echter voordat deze klaar is zijn we al bijna een minuut verder. Dan is alles alweer up

Edit 2:
Wireshark ook continue draaien nu met een filter op mijn server ip...

Kees schreef op vrijdag 10 februari 2017 @ 09:37:
Tja, of verkeer wel of niet bij apache kan komen zul je moeten testen tijdens zo'n downtime. Ik zelf zou het debuggen met de volgende stappen:

- als eerste, zet tcpdump aan zodat je alles logged wat jij naar de server stuurt (op poort 80)
- kan ik connecten naar poort 80? (nmap -sT -p 80 domein.nl)
- kan ik een eenvoudige request doen? (wget http://domein.nl/robots.txt)
- op de server zelf; wat zeggen ps auxfww, top, dmesg, en andere logs?
- strace -ff -ttt -o apache.trace -p $pid-van-apache

Maar hier komt wel vrij veel informatie uit waar je niet altijd even makkelijk een oorzaak uit kan halen

- Wireshark loopt, en in mijn browser /server-status/ met een auto-refresh plugin op 5 seconde
- Ik heb tcproute voor windows gevonden en 'klaar' staan voor als ik het opmerk
- Nee, ik heb het geprobeerd met een gifje op 1 van de sites
- CPU usage, load, etc is allemaal binnen proporties. Andere logs is niets vreemds te vinden.
- strace?

Nu maar weer afwachten dus.

[ Voor 71% gewijzigd door Verwijderd op 11-02-2017 15:17 ]

[Verwijderd]

Gebeurde net weer, helaas te laat met tcproute starten, maar heb het wel gecaptured in Wireshark.

Er zijn ook wat regels donker rood, maar wat ik er precies uit zou moeten halen, geen idee haha

[Verwijderd]

Gebeurde net weer, tcproute gestart. Op het moment dat tcproute klaar was was de server ook alweer 'up' dus dit zei niets zinnigs.

Hier een screenshot van Wireshark:

[goarilla]

Ik denk eerder aan IO/VM issues wanneer ik dit hoor (vmstat, iostat, dmesg). Ik vermoed dat er plots zwaar geswapped moet worden wanneer er meer threads/workers nodig zijn. Maar sinds je een VPS draait kan het natuurlijk ook zijn dat er slechte gebruikers op dezelfde host zitten.

[Verwijderd]

Er word niet/nauwelijks geswapped, heb sinds gisteren munin ook weer draaien:



Edit:

Het lijkt erop dat Wireshark de capture niet helemaal goed heeft gedaan. Ik zag alleen uitgaand verkeer in die sessies. Ik heb het herstart met hetzelfde capture filter en nu loopt hij wel goed.

Daarnaast is misschien het volgende nog handig om toe te voegen, alle domeinen hebben een eigen IPv4 en IPv6 adres. En alle domeinen gaan tegelijk 'down'.

[ Voor 55% gewijzigd door Verwijderd op 12-02-2017 22:47 . Reden: Toevoeging ]

[Verwijderd]

Kees schreef op vrijdag 10 februari 2017 @ 09:37:
Tja, of verkeer wel of niet bij apache kan komen zul je moeten testen tijdens zo'n downtime. Ik zelf zou het debuggen met de volgende stappen:

- als eerste, zet tcpdump aan zodat je alles logged wat jij naar de server stuurt (op poort 80)
- kan ik connecten naar poort 80? (nmap -sT -p 80 domein.nl)
- kan ik een eenvoudige request doen? (wget http://domein.nl/robots.txt)
- op de server zelf; wat zeggen ps auxfww, top, dmesg, en andere logs?
- strace -ff -ttt -o apache.trace -p $pid-van-apache

Maar hier komt wel vrij veel informatie uit waar je niet altijd even makkelijk een oorzaak uit kan halen

Gebeurde net alweer, hier een screenshot van Wireshark. Ik heb uiteraard de file opgeslagen:



Tijdens dit moment van downtime ook de tcproute tool (windows) kunnen draaien, om de wireshark log niet in de war te gooien heb ik dit gedaan op een ip adres van een andere website op de server.

code:

Ensuring gateway address (192.168.1.1) is in arp... OK!

Using the following values:
---------------------------
Local IP:    192.168.1.14
Local MAC:   20:68:9D:EB:00:BC
Gateway MAC: A0:21:B7:9F:85:1A
Remote IP:   149.210.xxx.xxx

Tracing route to 149.210.xxx.xxx:80
  1        36 ms        192.168.1.1     TimeExceeded
  2         8 ms        10.207.48.1     TimeExceeded
  3        10 ms        dv-rc0001-cr101-xe-1-0-4-0.core.as9143.net [213.51.185.60]      TimeExceeded
  4        11 ms        asd-tr0042-cr101-ae53-0.core.as9143.net [213.51.158.0]  TimeExceeded
  5        11 ms        amsix.router1.dcga.ams.transip.net [80.249.208.244]     TimeExceeded
  6        20 ms        v632.coreswitch1.dcgd.ams.transip.net [87.253.141.242]  TimeExceeded
  7        11 ms        v650.switch1.pool10.transip.nl [87.253.141.211] TimeExceeded
  8        28 ms        hostname.nl [149.210.xxx.xxx]:80      Synchronize, Acknowledgment (port open)

Exact hetzelfde resultaat als op andere momenten, ik denk dat ik gek word

Het verzoek aan /server-status/ van 00:05:17 en 00:05:47 verschijnen beide in de access logs om 13/Feb/2017:00:06:06. Er zijn 2 verzoeken gedaan omdat de auto-refresh in mijn browser op 30 seconde staat.

/var/log/messages rond het tijdstip:

code:

Feb 13 00:04:54 server kernel: Firewall: *TCP_IN Blocked* IN=eth0 OUT= MAC=52:54:00:44:02:68:f8:b1:56:61:e1:fa:08:00 SRC=123.243.101.176 DST=149.210.xxx.xxx LEN=40 TOS=0x00 PREC=0x00 TTL=240 ID=31888 PROTO=TCP SPT=31693 DPT=7547 WINDOW=14600 RES=0x00 SYN URGP=0 
Feb 13 00:04:58 server kernel: Firewall: *TCP_IN Blocked* IN=eth0 OUT= MAC=52:54:00:44:02:68:f8:b1:56:61:e1:fa:08:00 SRC=71.6.135.131 DST=149.210.xxx.xxx LEN=40 TOS=0x08 PREC=0x20 TTL=110 ID=20022 PROTO=TCP SPT=36877 DPT=17000 WINDOW=44569 RES=0x00 SYN URGP=0 
Feb 13 00:05:03 server kernel: Firewall: *TCP_IN Blocked* IN=eth0 OUT= MAC=52:54:00:44:02:68:f8:b1:56:61:e1:fa:08:00 SRC=67.102.143.182 DST=149.210.xxx.xxx LEN=40 TOS=0x00 PREC=0x00 TTL=243 ID=45248 PROTO=TCP SPT=62741 DPT=7547 WINDOW=14600 RES=0x00 SYN URGP=0 
Feb 13 00:05:21 server kernel: Firewall: *TCP_IN Blocked* IN=eth0 OUT= MAC=52:54:00:44:02:68:f8:b1:56:61:e1:fa:08:00 SRC=91.218.84.24 DST=149.210.xxx.xxx LEN=40 TOS=0x00 PREC=0x00 TTL=248 ID=57270 PROTO=TCP SPT=29247 DPT=23 WINDOW=14600 RES=0x00 SYN URGP=0 
Feb 13 00:05:33 server pure-ftpd: (?@80.69.67.10) [INFO] New connection from 80.69.67.10
Feb 13 00:05:34 server pure-ftpd: (?@80.69.67.10) [INFO] Logout.
Feb 13 00:05:42 server kernel: Firewall: *TCP_IN Blocked* IN=eth0 OUT= MAC=52:54:00:44:02:68:f8:b1:56:61:e1:fa:08:00 SRC=78.187.168.169 DST=149.210.xxx.xxx LEN=44 TOS=0x00 PREC=0x00 TTL=243 ID=23887 PROTO=TCP SPT=37730 DPT=23 WINDOW=14600 RES=0x00 SYN URGP=0 
Feb 13 00:05:53 server kernel: Firewall: *TCP_IN Blocked* IN=eth0 OUT= MAC=52:54:00:44:02:68:f8:b1:56:61:e1:fa:08:00 SRC=82.221.105.7 DST=149.210.xxx.xxx LEN=40 TOS=0x08 PREC=0x20 TTL=119 ID=65030 PROTO=TCP SPT=18242 DPT=1234 WINDOW=47011 RES=0x00 SYN URGP=0 
Feb 13 00:05:57 server kernel: Firewall: *TCP_IN Blocked* IN=eth0 OUT= MAC=52:54:00:44:02:68:f8:b1:56:61:e1:fa:08:00 SRC=183.237.31.238 DST=149.210.xxx.xxx LEN=44 TOS=0x00 PREC=0x20 TTL=239 ID=1454 PROTO=TCP SPT=15023 DPT=5358 WINDOW=14600 RES=0x00 SYN URGP=0 
Feb 13 00:06:33 server pure-ftpd: (?@80.69.67.10) [INFO] New connection from 80.69.67.10
Feb 13 00:06:34 server pure-ftpd: (?@80.69.67.10) [INFO] Logout.

De ftp connectie is de monitoring van TransIP

[ Voor 36% gewijzigd door Verwijderd op 13-02-2017 00:26 ]

[Kees]

De /server-status pagina's kwamen bij jou dus wel goed binnen tijdens de downtime of begrijp ik dat verkeerd?

Daarnaast, probeer een ps auxfww te vangen tijdens zo'n downtime, dan zie je mischien heel veel processen in een 'D' status en weet je dat het de disken zijn, of apache doet moeilijk en mischien zie je daar wat van).

Daarnaast is een strace (-ff -ttt -o apache.strace) wel een handige manier om te zien of apache ergens op locked (en waarop). Maar dat geeft je wel gigabytes aan data, dus dan zul je vrij goed moeten weten hoe je erin moet zoeken (hint: excel kan een handige tool ervoor zijn, daar kun je eenvoudig timestamps in een grafiek stoppen en zien waar er hele grote 'bumps' zijn).

[ Voor 7% gewijzigd door Kees op 13-02-2017 09:35 ]

[Verwijderd]

Nee de status pagina's kwamen ook niet binnen, de auto refresh tool refresht gewoon ongeacht de status, dus hij refresht tussentijds een keer terwijl de response er nog niet was.
Ik zet SSH vast open en wacht tot het weer gebeurd, eens zien wat ps auxfww zegt.

Wordt vervolgd.

[Verwijderd]

Kees schreef op maandag 13 februari 2017 @ 09:35:
De /server-status pagina's kwamen bij jou dus wel goed binnen tijdens de downtime of begrijp ik dat verkeerd?

Daarnaast, probeer een ps auxfww te vangen tijdens zo'n downtime, dan zie je mischien heel veel processen in een 'D' status en weet je dat het de disken zijn, of apache doet moeilijk en mischien zie je daar wat van).

Zojuist gebeurde het weer, en heb de output van ps auxfww naar een logfile geschreven.
Er staat geen enkel proces in 'D' status.

Omdat het een lap tekst is, heb ik het even op pastebin geplaatst:
http://pastebin.com/49R18UkK

[Thralas]

In je eerste tcpdump lijken zelfs je SYNs niet beantwoord te worden. Vrij kwalijk voor iets dat in-kernel gebeurt, daar heeft Apache (als het goed is) vrij weinig over te vertellen.

Getuige de lfd-daemon draai je csf. Heb je al geprobeerd die uit te zetten, en heel grondig na te gaan of die geen roet in het eten gooit? Desnoods met een iptables-save in een goed/stuk-situatie.

Kan eigenlijk niet missen...

[Verwijderd]

Klopt ik draai CSF, maar ben er een beetje huiverig voor om die zomaar uit te schakelen. Een goed alternatief ervoor weet ik ook niet. Is er een andere manier om zoiets te testen? Ik kan moeilijk CSF uitknallen en als het dan 3 dagen niet optreed zeggen dat het daar aan lag ;-)

[Thralas]

Ongetwijfeld heeft het logs (waarvan je al wat leek te hebben gepost, maar ik zie iig. aanleiding om nog wat beter te graven).

Anders zou je iptables-save kunnen gebruiken (zie vorige post). Of misschien nog handiger: iptables -v -L -n, dan heb je de packet counters er ook bij.

[Ruubster]

Wat ik me meer afvraag, is waarom draai je Apache 2.4.25 in combinatie met CentOS 6.8? Dat is niet standaard, voor zover ik weet zit CentOS 6.x op Apache 2.2, en Centos 7.x op 2.4.12 of iets in die richting. Dat is niet voor niks, heeft te maken met stabiliteit en beveiliging.

Dus heb je dit zelf 'handmatig' geïnstalleerd? En zo ja, waarom? Of wordt dit vanuit DirectAdmin geïnstalleerd...? Ik weet het niet zeker namelijk, heb geen ervaring met DirectAdmin.

[Verwijderd]

Ruubster schreef op dinsdag 14 februari 2017 @ 22:03:
Wat ik me meer afvraag, is waarom draai je Apache 2.4.25 in combinatie met CentOS 6.8? Dat is niet standaard, voor zover ik weet zit CentOS 6.x op Apache 2.2, en Centos 7.x op 2.4.12 of iets in die richting. Dat is niet voor niks, heeft te maken met stabiliteit en beveiliging.

Dus heb je dit zelf 'handmatig' geïnstalleerd? En zo ja, waarom? Of wordt dit vanuit DirectAdmin geïnstalleerd...? Ik weet het niet zeker namelijk, heb geen ervaring met DirectAdmin.

Dit zijn de versies die binnen komen via de update functionaliteit van DirectAdmin. Welke stabiliteitsproblemen zijn er mee bekend dan? Ik heb verder geen last van instabiliteit, het lijkt meer een netwerk issue inmiddels.

[Hero of Time]

DirectAdmin haalt maar weinig packages uit de CentOS repo. Als het al dingen uit een repo haalt, want het wil ook nog wel eens de boel gaan compileren voor je en dat kan ook gevolgen hebben. Het is een van de redenen dat ik persoonlijk zulke tools, DA vooral, verafschuw en mensen adviseer deze niet te gebruiken.

[Ruubster]

Inderdaad, als je de lijst met mogelijke stabiliteitsproblemen wil zien, die heb ik niet haha. Ik zeg alleen dat de waarschuwing is dat er stabiliteitsproblemen kunnen zijn. Maar het is een mogelijke bron voor je probleem.

[ Voor 3% gewijzigd door Ruubster op 15-02-2017 10:00 ]

[Verwijderd]

ik heb de output van iptables -v -L -n weten op te slaan tijdens een moment van downtime, en toen we weer up waren. Waar kan ik hierin het beste naar kijken?

[thunder7]

Om te beginnen naar het verschil tussen die twee outputfiles, lijkt me.

[Verwijderd]

In de files zie ik geen noemenswaardige verschillen.
Net gebeurde het weer, terwijl het 'gebeurde' heb ik CSF+LFD uitgeschakeld. En direct erna, kon ik de website nog niet benaderen.
Apache een restart geven, en direct kon ik er weer op.

Ik ga vannacht eens Apache downgraden naar 2.2, en zien wat het resultaat is. Als de stabiliteit dan nog niet verbeterd, maar een nieuwe VPS installeren.

[duiveltje666]

Downgraden lijkt me niet zo heel smart , support voor Apache 2.2.x eindigt eind dit jaar...

[Hero of Time]

duiveltje666 schreef op zondag 19 februari 2017 @ 13:58:
Downgraden lijkt me niet zo heel smart , support voor Apache 2.2.x eindigt eind dit jaar...

En dit jaar is pas begonnen. Dus wat is je punt? Dat je nu niet meer kan testen of een oudere release van apache dezelfde vreemde problemen geeft?

[duiveltje666]

Hero of Time schreef op zondag 19 februari 2017 @ 14:15:
[...]

En dit jaar is pas begonnen. Dus wat is je punt? Dat je nu niet meer kan testen of een oudere release van apache dezelfde vreemde problemen geeft?

Ik zeg niet dat het niet kan , ik zeg dat het niet wenselijk is.
Mocht Apache 2.2.x nml wel werken zonder problemen , wil je dan daarop door blijven draaien wetende dat je eind van het jaar gewoon screwed bent met je support?
Ik ben de afgelopen jaren ook wat irritante issues mbt Apache tegengekomen die me uiteindelijk gewoon de switch naar Nginx hebben laten maken , na 15 jaar alle branches van Apache gebruikt te hebben

[Blokker_1999]

duiveltje666 schreef op zondag 19 februari 2017 @ 14:20:
[...]

Ik zeg niet dat het niet kan , ik zeg dat het niet wenselijk is.
Mocht Apache 2.2.x nml wel werken zonder problemen , wil je dan daarop door blijven draaien wetende dat je eind van het jaar gewoon screwed bent met je support?
Ik ben de afgelopen jaren ook wat irritante issues mbt Apache tegengekomen die me uiteindelijk gewoon de switch naar Nginx hebben laten maken , na 15 jaar alle branches van Apache gebruikt te hebben

Nee, maar dan weet je ineens wel dat het probleem bij de nieuwe Apache versie zit en kan je veel gerichter gaan zoeken naar een oorzaak en gevolg.

[Verwijderd]

Idd vanavond staat de downgrade gepland, maar als het dan opgelost is weet ik iig waar ik het zoeken moet ;-)

[Hero of Time]

Pak je met de downgrade de directadmin manier, of pak je apache uit de repo via yum installatie httpd?

[duiveltje666]

Blokker_1999 schreef op zondag 19 februari 2017 @ 18:16:
[...]

Nee, maar dan weet je ineens wel dat het probleem bij de nieuwe Apache versie zit en kan je veel gerichter gaan zoeken naar een oorzaak en gevolg.

Ja en wat ga je dan doen? wachten op een nieuwe release? ik vraag me uberhaupt af of ie FPM gebruikt , mod_php of iets anders..
Apache staat er bekend om om nogal geheugen te vreten zonder noodzaak ..

[Verwijderd]

Even een update:

Ik wou de directadmin manier van downgraden pakken, maar 2.2 werd inmiddels al niet meer ondersteund.
Op het forum van DA kwam ik diverse meldingen tegen van mensen die problemen hebben met 2.4.26 icm HTTP 2.

De problemen die men had, leken op die van mij, terwijl ik niet de specifieke HTTP 2 installatie draai. Dus heb ik 2.4.23 weer gepakt, en de problemen lijken nu 3 dagen voorbij. Nog even afwachten dus.

[Hero of Time]

Dus toch iets met de versie van DA. Dit is dus waarom ik geen control panel achtige zaken wil om een server te beheren. Je weet niet wat er precies gebeurt en wat er buiten het idee van de distro om gebeurt.

[Verwijderd]

Ja maar ik ben van achtergrond iemand die zich bezig houd met ontwikkeling ;-)
We hadden eerder een 'managed' server bij een partij, maar die deden hun werk nog slechter.

Sinds een jaartje doe ik het voornamelijk zelf, en zijn we vooral in performance vele malen sneller (en enkele honderden euro's per maand goedkoper uit).
Het is lastig een betrouwbare partij te vinden, die dit wil doen icm een TransIP VPS

[Hero of Time]

En je hebt niet gedacht aan TransIP om de server te laten beheren mbt software en updates waarbij jij alleen maar hoeft te ontwikkelen wat het serveert?

[Verwijderd]

Dat doen ze helaas niet voor VPS-en

[_JGC_]

Http2 op 2.4.25 is brak. Houd er rekening mee dat 2.4.23 diverse security en/of DoS bugs heeft.

Ik draai zelf 2.4.25 met een snapshot uit de 2.4.x branch voor de http2 module.

[Verwijderd]

Kan dit probleem te maken hebben met het 'semaphores'?
Tot gisteren wist ik niet wat het was, dus als ik een domme vraag stel kijk niet raar.

Vannacht tijdens de logrotate kon apache niet herstarten, met een foutmelding tot gevolg:

code:

(28)No space left on device: AH00023: Couldn't create the rewrite-map mutex 
AH00016: Configuration Failed

Dankzij google was dit ook zo opgelost met het opruimen van de eerder genoemde semaphores. Maar ik dacht, misschien hadden mij eerdere problemen hier ook mee te maken.

[Hero of Time]

Als je issues hebt met semaphores dan heb je een flinke bug te pakken. Er moet echt iets goed mis zijn om daar uit te lopen. Heb 't 1x gezien en dat kwam doordat een proces (daemon/service) gewoon niet fatsoenlijk afsloot. Toevallig ook Apache, maar niet 2.4.

[Verwijderd]

Ja, daar lag het vannacht echt aan, nadat ik ze verwijderd had restartte de boel gewoon. :-)
Er is bijna 24/7 wel iemand die de boel in de gaten houd, dus op het moment doen we het maar zoals het nu loopt tot apache met een update komt. Ik ben zelf te druk met andere zaken om hier verder nog tijd in te steken.

Allen bedankt voor de hulp! Als het topic geen slotje krijgt, zal ik eventuele verdere updates gewoon blijven posten.