Fórum Root.cz
Hlavní témata => Server => Téma založeno: Rhinox 31. 05. 2016, 20:41:08
-
Kdyz uz jsou tady ty oslavne clanky na systemd, mohl by mi nekdo vysvetlit, proc mi furt umira apache, na minimalne zatizenem servru, v prumeru kazdy 2-3 dny? A proc ho kur*a systemd znovu nenastartoval???
[root@vepusix etc]# systemctl status httpd
● httpd.service - The Apache HTTP Server
Loaded: loaded (/usr/lib/systemd/system/httpd.service; enabled; vendor preset: disabled)
Active: failed (Result: exit-code) since Mon 2016-05-30 13:46:22 UTC; 1 day 4h ago
Docs: man:httpd(8)
man:apachectl(8)
Process: 27587 ExecStop=/bin/kill -WINCH ${MAINPID} (code=exited, status=1/FAILURE)
Process: 26685 ExecReload=/usr/sbin/httpd $OPTIONS -k graceful (code=exited, status=0/SUCCESS)
Process: 19881 ExecStart=/usr/sbin/httpd $OPTIONS -DFOREGROUND (code=killed, signal=KILL)
Main PID: 19881 (code=killed, signal=KILL)
Status: "Total requests: 0; Current requests/sec: 0; Current traffic: 0 B/sec"
May 20 17:51:34 vepusix systemd[1]: Reloaded The Apache HTTP Server.
May 20 18:05:22 vepusix systemd[1]: Reloaded The Apache HTTP Server.
May 29 03:12:03 vepusix systemd[1]: Reloaded The Apache HTTP Server.
May 30 03:29:02 vepusix systemd[1]: Reloaded The Apache HTTP Server.
May 30 13:46:13 vepusix systemd[1]: httpd.service: main process exited, code=killed, status=9/KILL
May 30 13:46:27 vepusix systemd[1]: httpd.service: control process exited, code=exited status=1
May 30 13:46:27 vepusix systemd[1]: Unit httpd.service entered failed state.
May 30 13:46:27 vepusix systemd[1]: httpd.service failed.
May 30 13:46:28 vepusix kill[27587]: kill: cannot find process ""
May 01 07:44:03 vepusix systemd[1]: Reloaded The Apache HTTP Server.
[root@vepusix ~]# journalctl -u httpd.service
May 30 13:46:13 vepusix systemd[1]: httpd.service: main process exited, code=killed, status=9/KILL
May 30 13:46:27 vepusix systemd[1]: httpd.service: control process exited, code=exited status=1
May 30 13:46:27 vepusix systemd[1]: Unit httpd.service entered failed state.
May 30 13:46:27 vepusix systemd[1]: httpd.service failed.
May 30 13:46:28 vepusix kill[27587]: kill: cannot find process ""
Kdyz ho nahodim rucne, pobezi zas par dni, a pak umre. Pameti mam dost, a pred apachem je jeste varnishd. Proc mi tedy ten prokletej indian porad pada???
-
A proc ho kur*a systemd znovu nenastartoval???
Asi v /usr/lib/systemd/system/httpd.service chybí:
Restart=on-failure(výchozí je no, tedy že se nic nerestartuje)
Main PID: 19881 (code=killed, signal=KILL)
Tohle říká, že mu někdo poslal SIGKILL. To typicky dělá OOM killer. Opravdu je tam dost paměti? Není v dmesg informace o OOM?
-
v /usr/lib/systemd/system/httpd.service nic takoveho nemam! To mam snad editovat soubory v /usr/lib? Co je tohle za bordel?
dmesg je prazdnej, nic o OOM tam neni. Na serveru je 4GB RAM, pouzito kolem 300MB. Web-servr je prazdnej, jen jedna staticka stranka. Apache bezi jen na loopbacku, dostupnej jen pres varnish.
Neni mozne aby naraz neco sezralo ~3.5GB. Krom toho, pada jenom apache, nic jinyho. Nevim dle jake logiky pracuje OOM, jen tipuju ze by snad neshazoval porad jenom apache. A v logu neni nic ohledne pameti, melo by tam snad byt neco jako "Out of memory"...
-
v /usr/lib/systemd/system/httpd.service nic takoveho nemam! To mam snad editovat soubory v /usr/lib? Co je tohle za bordel?
No to ti snad Sten rikal, ze to tam nejspis nebude, kdyz se to nepouziva.
Co si precist fajnovy manual?
https://www.freedesktop.org/software/systemd/man/systemd.unit.html
Example 2. Overriding vendor settings
-
verze apache, distro?
Hele nejspis to nebude tvuj pripad, ale ja se tuhle natrapil s tim, ze apache nezvladl reload(asi v 3/4 pripadu, naprosto random, blbe bylo ze se mu to nekdy povedlo tak se to blbe hledalo ten problem) a sestreloval mi ho logrotate v nedeli rano, lahudka (tak jsem v nem nastavil restart a od ty doby dobry).
-
verze apache, distro?
Apache 2.4.6, Centos7/64b
-
v /usr/lib/systemd/system/httpd.service nic takoveho nemam! To mam snad editovat soubory v /usr/lib? Co je tohle za bordel?
Můžeš nastavit drop-in v /etc/systemd, pokud ti to bude víc vyhovovat. Přidej soubor /etc/systemd/system/httpd.service.d/restart.conf s obsahem:
[Service]
Restart=on-failure
A reloadovat systemd pomocí systemctl daemon-reload. Jestli to funguje, můžeš ověřit pomocí systemctl cat httpd.service, měl by ten drop-in vypsat na konci.
-
Mimochodem není to virtuál v LXC nebo OpenVZ, kde běží Apache na hostiteli?
-
Mimochodem není to virtuál v LXC nebo OpenVZ, kde běží Apache na hostiteli?
Je to VPS (OpenVZ), apache bezi v nem...
-
Mimochodem není to virtuál v LXC nebo OpenVZ, kde běží Apache na hostiteli?
Co by z toho plynulo?
-
V paravirtualizaci lze RAMku masivně sdílet mezi uživateli. Samozřejmě, že to jde nastavit dobře, ale proč by to administrátor dělal, když na tom může vydělat pořádný prachy ;D tzn. prodat tu ramku stokrát. Tuším že to ani v logách není, jen v accountingu VPSky.
Mimochodem není to virtuál v LXC nebo OpenVZ, kde běží Apache na hostiteli?
Co by z toho plynulo?
-
V paravirtualizaci lze RAMku masivně sdílet mezi uživateli. Samozřejmě, že to jde nastavit dobře, ale proč by to administrátor dělal, když na tom může vydělat pořádný prachy ;D tzn. prodat tu ramku stokrát. Tuším že to ani v logách není, jen v accountingu VPSky.
To by ale snad nesestřelilo procesy v guestu, spíš by jenom host začal swapovat, ne?
A navíc by se Sten neptal, jestli na hostu neběží ausgerechnet Apache. Pochopil jsem ten dotaz tak, že vzniká nějaký problém, když Apache běží v hostu i guestu.
-
Mimochodem není to virtuál v LXC nebo OpenVZ, kde běží Apache na hostiteli?
Co by z toho plynulo?
Procesy v hostiteli vidí procesy na všech virtuálech. Apache pak má takovou ošklivou vlastnost, že když vidí jiné procesy Apache, které nereagují na reload třeba při logrotate, tak je postřílí.
Mimochodem není to virtuál v LXC nebo OpenVZ, kde běží Apache na hostiteli?
Je to VPS (OpenVZ), apache bezi v nem...
OpenVZ má ještě bean countery, které mohou způsobovat problémy. S Apache jsem měl často problém s nedostatkem shmpages. Zkusil bych se podívat do /proc/user_beancounters, jestli nějaké nemají nenulový failcnt.
Druhá věc u OpenVZ je, že dmesg ve virtálu nevypisuje skoro nic a free není (nebo alespoň nebyl, když jsem OpenVZ naposledy používal, což už jsou tři roky) ani orientační, tak pokud jsi hledal je ve virtuálu, ten OOM kill tam nemusel být vidět.
-
Apache pak má takovou ošklivou vlastnost, že když vidí jiné procesy Apache, které nereagují na reload třeba při logrotate, tak je postřílí. [...] tak pokud jsi hledal je ve virtuálu, ten OOM kill tam nemusel být vidět.
Hmmmmm, tak to jsou teda hodně dobrý špeky! Dík.
-
Osobně jsem názoru, že LXC nebo OpenVZ se nehodí pro zcela běžné uživatele.
Jsou to spíš technologie pro firmu, která potřebuje dobrou správu, vysoký výkon a tím pádem i optimální využití hardware (má celý ten svůj cloud pod kontrolou).
Lze to sice nastavit podobně jako "běžnou" virtualizaci, ale to není vlastně cíl těchto technologií a naprosté nepochopení je vidět v různých fórech po internetu končícím (dám tam KVM jako kdyby to snad byl stejný produkt).
Většina lidí se prostě utopila v accountingu toho stroje, asi příliš futuristické - nepřišel čas, možná za pár let s LXC se to znovu vynalezne.
To s tím apachem je teda hnusný, ale v době systemd mě asi nic nešokuje. Dneska co se samo nerestartuje, tak je vlastně nefunkční :)
-
Procesy v hostiteli vidí procesy na všech virtuálech. Apache pak má takovou ošklivou vlastnost, že když vidí jiné procesy Apache, které nereagují na reload třeba při logrotate, tak je postřílí.
Druhá věc u OpenVZ je, že dmesg ve virtálu nevypisuje skoro nic a free není (nebo alespoň nebyl, když jsem OpenVZ naposledy používal, což už jsou tři roky) ani orientační, tak pokud jsi hledal je ve virtuálu, ten OOM kill tam nemusel být vidět.
Nevim jak funguje openvz ale pochybuju ze kazdej proces v hostu vidi vsechny procesy ve vsech openvz-kontejnerech.
Taky nechapu proc by hostingova firma nechala na openvz-serveru bezet apache...
No nic, pustim si skript co kazdou vterinu koukne kolik je volne pameti a zacne logovat jakmile se dostane pod 50% free. Snad to zachyti. Ovsem osobne si nemyslim ze apache je odstrelenej kvuli tomu...
-
Zkusil bych v první řadě položit dotaz přímo té hostingové firmě. Třeba ten signál opravdu přichází od hostitele a oni už budou vědět, proč se to děje.
-
To s tím apachem je teda hnusný, ale v době systemd mě asi nic nešokuje. Dneska co se samo nerestartuje, tak je vlastně nefunkční :)
Tohle je pozůstatek sysvinitu, kdy se signalizuje jen řídicí proces. V době systemd takové chování vůbec není potřeba, protože se o to umí postarat systemd.
Nevim jak funguje openvz ale pochybuju ze kazdej proces v hostu vidi vsechny procesy ve vsech openvz-kontejnerech.
Vidí, je to tak u každé kontejnerové virtualizace. A je to proto, aby bylo možné profilovat případné výkonnostní problémy přes nástroje jako top a iotop.
Taky nechapu proc by hostingova firma nechala na openvz-serveru bezet apache...
To nevím. Původně jsem předpokládal, že si tu virtualizaci děláte sám (protože většinou dělám s KVM či bare HW a kontejnery mám tedy vždy pod plnou kontrolou). Hostingová firma by ale asi měla vědět, že to nemá dělat.
No nic, pustim si skript co kazdou vterinu koukne kolik je volne pameti a zacne logovat jakmile se dostane pod 50% free. Snad to zachyti. Ovsem osobne si nemyslim ze apache je odstrelenej kvuli tomu...
Což vzhledem k tomu, že free v OpenVZ moc dobře nefunguje (nefungovalo?), nemusí nic zjistit.
Obrátil bych se v tomto případě na hostingovou firmu. Můžete ještě přidat FailureAction pro tu službu a třeba zalogovat všechny běžící procesy.
Mimochodem co ty bean countery?
-
...protože se o to umí postarat systemd.
Treba tak, ze to postrili vsechno kdyz se user odhlasi ze?
-
...protože se o to umí postarat systemd.
Treba tak, ze to postrili vsechno kdyz se user odhlasi ze?
Jojo, to je ultimátní řešení... Tenhle pošuk z Lennartovy církve tady opravdu scházel. ::)
-
...protože se o to umí postarat systemd.
Treba tak, ze to postrili vsechno kdyz se user odhlasi ze?
No vidíš, a Apache to dělá už roky ;)
-
...protože se o to umí postarat systemd.
Treba tak, ze to postrili vsechno kdyz se user odhlasi ze?
No vidíš, a Apache to dělá už roky ;)
Jenomze systemd spatny, apache dobry, beeeeee.
(nez se toho nekdo s nedostatkem schopnosti cist s porozumenim chopi - nerikam, ze by apache byla nejaka tragedie, jenom mi vadi, kdyz nekteri smichaji u SystemD naprosto validni kritiku - binarni log je klasika - s hazenim spiny za kazdou cenu)
-
Nevim dle jake logiky pracuje OOM, jen tipuju ze by snad neshazoval porad jenom apache.
Chyba lávky! Zde je vysvětlení (http://turnoff.us/image/en/oom-killer.png) :) :) :)
-
Odkdy je v OOM Killeru nebo Linuxu nejaka logika? OOM Killer je algoritmus prosteho mozku - jakmile zacne dochazet pamet, tak zacne zabijet nahodne procesy a zacne od tech co zerou nejvice (coz je v drtive vetsine pripadu to co chcete aby na serveru bezelo) a u toho se ale nezastavi, protoze ani to mu nepomaha a pokracuje dale az zabiji i procesy nutne pro beh system a pak booooom. Zrovna dneska jsem opet zazil.
-
Odkdy je v OOM Killeru nebo Linuxu nejaka logika? OOM Killer je algoritmus prosteho mozku - jakmile zacne dochazet pamet, tak zacne zabijet nahodne procesy a zacne od tech co zerou nejvice (coz je v drtive vetsine pripadu to co chcete aby na serveru bezelo) a u toho se ale nezastavi, protoze ani to mu nepomaha a pokracuje dale az zabiji i procesy nutne pro beh system a pak booooom. Zrovna dneska jsem opet zazil.
OOM killer má poměrně složitá pravidla výběru, nedělá to náhodně. Typicky začíná procesy, které běží pod nepriviligovanými uživateli, nemají TTY a mají velké nároky na paměť. Smysl není nechat běžet na serveru to, co si vy zrovna myslíte, že by mělo běžet pořád (to stejně nejde zaručit), ale umožnit administrátorovi se připojit a nějak ten problém vyřešit.
Pokud ani to nepomůže, pak je chyba mezi židlí a klávesnicí, kde se rozhodovalo, co všechno se na tom serveru s tak obrovským nedostatkem paměti spustí.
-
Tak sem si udelal skript, kterej kazdou vterinu kontroluje kolik % volne pameti mam a kdyby to bylo mene nez danej limit (50%), logne to do souboru (i s datumem/casem).
Po dvou dnech mi apache opet padnul, a skript nezaznamenal ani jeden pripad kdyby bylo mene volne pameti, nez 50% (t.j. 2GB)! Tak bud se pamet necim obsadila rychleji nez za vterinu, nebo apache pada kvuli necemu jinemu...
Ted sem vyhazel tak ~25 modulu co tam apache po standartni instalaci natahuje, a uvidim jestli to pomuze...
-
Tak sem si udelal skript, kterej kazdou vterinu kontroluje kolik % volne pameti mam a kdyby to bylo mene nez danej limit (50%), logne to do souboru (i s datumem/casem).
Po dvou dnech mi apache opet padnul, a skript nezaznamenal ani jeden pripad kdyby bylo mene volne pameti, nez 50% (t.j. 2GB)! Tak bud se pamet necim obsadila rychleji nez za vterinu, nebo apache pada kvuli necemu jinemu...
Ted sem vyhazel tak ~25 modulu co tam apache po standartni instalaci natahuje, a uvidim jestli to pomuze...
Mohol by si ten script uverejnit ? rad by som si ho pozrel ...
Mne sa presne toto minuly tyzden stalo, proste znicoho nic v niektorych pripadoch do 10 sekund spadol apache, OOM killer bezal na plne obratky ale nedostal sa ztoho.
Chyba bola vo webovej aplikacii ktora sa dostala do niakeho loopu a otvarala otvarala atd, smola bola ta ze na danu stranku nikto nechodil a sem tam mi ju otvoril google bot, apod.
Nemas tam chybnu aplikaciu ?
Dalsi problem bol ze mysql bol zle nastaveny a mohol si zobrat az 50 GB pamate a server mal 16 GB ...
-
Zkus nastavit auditd, něco ve stylu
auditctl -a always,exit -F path=/var/run/httpd.pid -F perm=r -F auid=0 -k rootkill
auditctl -a always,exit -F path=/bin/kill -F perm=x -F auid=0 -k rootkill
auditctl -a always,exit -S kill -F auid=0 -F pid=[mainpidofhttpdprocess] -k rootkill
-
Mohol by si ten script uverejnit ? rad by som si ho pozrel ...
Je to velice primitivni, dalo by se to udelat efektivneji, ale nechtelo se mi s tim parat...
#!/bin/bash
while true; do
# get % of free memory (only integer part)
freemem=$(free | grep Mem | awk '{print $4/$2 * 100.0}' | cut -d'.' -f1 -)
# set up warning limit
warnmem="50"
# compare
if [ "$freemem" -lt "$warnmem" ]; then
# less free memory than warning level
date >> /root/temp/memory.txt
echo "Free memory:" $freemem "%" >> /root/temp/memory.txt
fi
sleep 1;
done
Pustil sem to pak s "nohup script &" (mam jeste verzi systemd ktera nezabiji procesy po odhlaseni). Nebere to temer zadne cpu, jen kolem 1.5kB RES-pameti. BTW koukam ze dnes mi apache padnul po par hodinach. Tohle mi hlava nepobere!