Milyen rendszerfolyamat fut minden kerek 3 órában?

Linux-haladó

Van egy Debian alapú webszerver, ahol php-fpm szolgálja ki a kérelmeket. Mágikus módon azonban néha beragadnak az fpm szálak. Semmilyen konfiguráció nem segített eddig rajtuk, a timeout értékek egyáltalán nem érdeklik ilyenkor. Egyedül az fpm újraindítása teszi helyre. Ilyen beragadt állapotban a szerver terheltsége (CPU, IO) nem tér el az átlagostól, és elég alacsony. Több php verzió is van a szerveren, és bármelyikkel verzióval elő tud fordul. Lehet, hogy nem is a php-fpm hibája.(?)

Egyetlen érdekes tulajdonsága van, hogy az esetek 95%-ban 3*x óra:00-kor történik. Az óra 3-nal osztható véletlenszerű, a perc meg 00.

Végignéztem az időzített folyamatokat, és mindent, ami 00-kor indult, áttettem másik időpontra. Ennek ellenére továbbra is következetesen :00-kor történik, ha történik.

Milyen háttérfolyamat lehet az, ami mindig 00-kor fut le?

  • 767 megtekintés

( denton | 2023. 11. 22., sze – 17:04 )

Nem lehet, hogy egy végtelen ciklust sikerült összehozniuk a fejlesztőknek?

A verzió egy while(true) esetében mind1. (most csak mondtam egy elvetemült példát).

Régebben volt szokás olyan cronokat írni, hogy a rendszergazda berakott egy percenként lefuttatott php-t amiben van egy tonna if-else vagy switch-case és benne egy date fv-vel kérdi le pl, hogy éppen hány óra van, hány perc, és ha éppen mondjuk a perc az 0, akkor fog egy adott scriptet include-olni. Tehát házibarkács cron amikor még nem volt gyakori dolog külön cli job-okat írni, meg nem volt keretrendszer, stb.

 

Egyébként az fpm-nél úgy rémlik, hogy a folyamatokban látszik, hogy melyik php fájl fut nem?

Csak a pool látszik a folyamatokban, a konkrét kérelem nem.

Egyébként a verzió alatt azt értettem, hogy az a php verzió fagyna be, amelyikben ez a végtelen ciklus van. Nem a kód verziófüggő. De olyan php verzió is képes befagyni, amiről tudom, hogy a php kódban nincs semmi varázslás.

( NevemTeve | 2023. 11. 22., sze – 17:51 )

Gdb/strace segíthet kinyomozni a beragadás mibenlétét.

( x-daemon | 2023. 11. 22., sze – 18:13 )

amikor beragad akkor mi tortenik vagy mi nem tortenik?

milyen vas?

neked aztan fura humorod van...

Az történik, hogy a PHP kérelmekre nem, vagy csak nagyon lassan érkezik válasz. Innen is veszem észre, hogy előfordult, és ilyenkor újra tudom indítani az adott php verziót.

8 mag, 16GB RAM, SSD. Load értéke 1 körül vagy az alatt általában. Tehát erőforrás van bőven.

Ez jó ötlet, köszönöm, bár, hogy ennyire mindig kerek órában, de egymástól véletlen időtartamra lévőn ... Azért ennek kicsi a valószínűsége.

Közben annyit még felismertem a lefagyási időpontokat nézve, hogy nemcsak hogy óránként, hanem 3 óránként, haha 00:00 vagy 3:00 vagy 6:00 ... Így még furább.

Igen

systemclt list-timers --all, illetve az egyes usereké a user nevében futtatva systemctl list-timers --user --all. Sajnos az összes user unitjainak lekérdezésére nem nagyon van triviális módszer, a systemctl magától nem tudja, csak egyesével, és elég sok helyen lehetnek. Ha kell, végig lehet szaladni a passwdn egy forciklussal, vagy valami.

( x-daemon | 2023. 11. 22., sze – 18:14 )

cronban nincs semmi 0 ...-val?

neked aztan fura humorod van...

( uid_17626 | 2023. 11. 23., cs – 01:53 )

Szerkesztve: 2023. 11. 23., cs – 01:55

Lehet nem nálad van időzítve, hanem egy php kérést url-n keresztül időzítve hívnak meg.

Lásd webszerver log, sql long / large query

Akkor várhatóan egy adott php verzió állna csak be, amelyikben a mágikus kód van.

A php logban nem látok releváns bejegyzést. De félek, ez is úgy működik, mint az Apache, amelyik csak a sikeres kérelem után készíti el a naplóbejegyzést.

( zsolt | 2023. 11. 23., cs – 13:03 )

systemd timereit nem nézted? Nálam pl phpsessionclean.service félóránként fut, de ez ubuntu.

Vagy pl prometheus szerver 2 óránként szokott csinálni valamit teljesen magától, de syslogban van nyoma.