PlayStation Network (PSN) má již několik hodin, vlastně celou sobotu, masivní výpadek (Stav služby PSN, X).
Vývojáři open source storage platformy TrueNAS oznámili, že s verzí 25.04 s kódovým názvem Fangtooth končí TrueNAS CORE postavený na FreeBSD a TrueNAS SCALE postavený na Linuxu. Jejich společným pokračováním bude TrueNAS Community Edition postavený na Linuxu.
Mapy Google dnes slaví 20 let. Spuštěny byly 8. února 2005. Svět se přesunul od papírových map k digitálním. A ke Street View, Live View, Immersive View, …
Hector "marcan" Martin, vedoucí projektu Asahi Linux aneb Linux na Apple Siliconu, skončil jako upstream vývojář linuxového jádra. Se slovy "už nemám žádnou důvěru v proces vývoje jádra … další vývoj Apple/ARM bude pokračovat downstream" odstranil své jméno ze souboru MAINTAINERS. Důvodem jsou neshody kolem Rustu v linuxovém jádru [Hacker News, No rust code in kernel/dma, please.].
Mistral AI včera představil nový vylepšený Le Chat. Nově také jako aplikace pro iOS a Android.
Britské bezpečnostní orgány nařídily americké firmě Apple, aby vytvořila takzvaná "zadní vrátka", která by umožnila dostat se k šifrovanému obsahu uživatelů uloženému v cloudu. Tajné nařízení, vydané v lednu, vyžaduje plošný přístup k šifrovanému účtu jakéhokoliv uživatele přístrojů Apple kdekoliv na světě. Britské úřady tedy Apple nežádají pouze o asistenci s přístupem k účtu konkrétního uživatele, ale rovnou chtějí mít přístup ke všem účtům, kdykoliv budou chtít.
Byla vydána (𝕏) lednová aktualizace aneb nová verze 1.97 editoru zdrojových kódů Visual Studio Code (Wikipedie). Přehled novinek i s náhledy a animovanými gify v poznámkách k vydání. Ve verzi 1.97 vyšlo také VSCodium, tj. komunitní sestavení Visual Studia Code bez telemetrie a licenčních podmínek Microsoftu.
Nedávno se povedlo do pdf souborů vložit Tetris a DOOM a po otevření příslušného pdf souboru v na Chromiu založeném webovém prohlížeči vybranou hru přímo v pdf spustit. LinuxPDF ukazuje, že do pdf lze vložit také RISC-V emulátor a rozběhnout Linux.
Kancelářský balík LibreOffice byl vydán ve verzi 25.2. Podrobnosti v poznámkách k vydání.
Ahoj, prosím o radu s následujícím problémem.
Na serveru jsem měl httpd (Apache) verze 2.x. (Nevím už přesně, která verze to byla.) Server bez problémů fungoval, včetně PHP a přístupu k databázi.
Po aktualizaci (balíčkovacím systémem ArchLinuxu) na verzi 2.2.6 přestal fungovat. Jakýkoliv dotaz způsobí zatuhnutí démona se 100% využitím CPU.
Web tedy samozřejmě nefunguje a každý další pokus o načtení www stránky spustí další proces httpd, který opět využívá CPU, jak nejvíc může.
Po zamrznutí jsou procesy httpd nesmrtelné. Nelze je zabít žádným způsobem kromě restartu. Zdůrazňuji, že nejde o zombie procesy. Tyto využívají procesor velmi náruživě.
V logu nic podezřelého není. Možná bych měl zapnout jinou úroveň logování... Ale kterou?
Googlem jsem našel desítky odkazů o zamrzajících procesech httpd, ale vždy šlo o zombie nebo chybný PHP skript. Toto je zjevně jiný případ. Nemám ponětí, čím to může být.
Zkusím tedy LogLevel debug. Zatím to vypadá, že se do logu nepíše absolutně nic, ale třeba se tam při vyšším LogLevelu stihne ještě něco zapsat, než to zamrzne.
Týká se to všech virtual hostů. I těch, u kterých není PHP.
Tak teda fakt nevím, čím by to mohlo být. Zapnul jsem LogLevel debug.
Tvrdilo to jedinou podezřelou věc - že vypršela platnost CRL. Tedy jsem vygeneroval nový CRL a hláška tam už pak není.
Ale zamrzá to dál přesně stejně. Do access_log
se vůbec nic nezapíše, resp. nestihne zapsat. V error_log
u taktéž nic zajímavého není. Jediná hlášení typu error
vznikají ve chvíli, kdy se při restartu server vypíná a nemůže žádným způsobem zabít své zaseknuté potomky.
Takže co s tím? Přece nemůžu být jediný, kdo má tenhle problém... To by byla moc velká náhoda.
df cat /etc/hosts cat /etc/resolv.confNebude tam někde bordel? Zkoušel jste nedistribuční apache?
Filesystem 1K-blocks Used Available Use% Mounted on /dev/hda1 3937220 1763492 1973724 48% / none 144108 0 144108 0% /dev/shm /dev/hda2 15314684 11207300 3329440 78% /home /dev/hdc1 5699964 1153176 4257244 22% /var
127.0.0.1 localhost.localdomain localhost charon
nameserver 127.0.0.1
Pro úplnost ještě dodám, že nastavení je přesně stejné jako u původní verze Apache, která fungovala. Na tom serveru zároveň běží named
pro mou doménu, proto je sám sobě name serverem. (DNS funguje bez potíží.)
Jakmile ale přijde jakýkoliv http požadavek - bez ohledu na to, zda z vnitřní sítě nebo zvenčí - celý Apache se zasekne a nepomůže nic jiného než restart.
Už jsem měl podobný problém dvakrát. Jednou šlo (matně si vzpomínám) o problém s interpretem PHP (vyřešeno). Podruhé byl problém s šifrovacím enginem - špatný název souboru s klíčem (vyřešeno). Jenže v obou případech tam zůstávaly jen zombie, které nevyužívaly procesor. Tento případ je naprosto ojedinělý a asi kvůli němu brzy přijdu o nervy...
Nedistribuční apache jsem nezkoušel. (Kdysi ano, ale tuto verzi nikoliv.) Je poměrně složité to správně nakonfigurovat a v tuto chvíli na to nemám čas ani kuráž. Kdybych jenom převzal konfiguraci z PKGBUILD
u, získal bych stejný Apache... Jedině bych mohl někde splašit starší verzi, ale tím ten problém nezmizí.
Jste si opravdu jist, že to není chybný PHP skript nebo nějaký problém s přepisováním adres?
Aktualizoval jsem pouze software. Skripty zůstaly navlas stejné. Fungovaly předtím cca půl roku. Pokud jde o mod_rewrite
, nic takového nepoužívám.
Odhadoval bych, že problém je v tom, že se Apache pokouší rekurzivně vkládat do sebe jednu a tu samou stránku, nebo se přesměrovává neustále na jednu a tu samou adresu (případně navzájem mezi více adresami v kolečku).
To si nemyslím. Ani LogLevel debug
neukazuje nic podezřelého nebo snad cyklického... Kdyby třeba narůstala spotřeba paměti nebo kdyby se hodně logovalo, dá se z toho kdeco usoudit. Jenže ono nic. Jen procesor je zatížený na maximum. Jednou se mi hromadily instance httpd proto, že selhal jeden z harddisků a nešlo zapisovat do logu. Ale toto není ten případ.
Neaktualizovalo se s Apachem i PHP? Konfigurační soubory se změnily, nebo jsou tam stále ty samé?
PHP se aktualizovalo taktéž. PHP (prostě přímo příkaz php
) funguje - nechybí žádné knihovny nebo tak něco. Konfigurační soubory jsou původní. Časem se chystám provést nějaký merge, ale to bude dlouhá a nepříjemná procedura...
Zkusil bych nejprve vyloučit problém se skriptem nebo přesměrováním – vypnout všechny rewrite a zkusit načíst nějakou statickou stránku.
Provedeno. Přepisování nepoužívám. Mám hned několik virtuálních hostů se statickými stránkami. Bohužel taktéž nefungují. Dopadne to stejně, ať přistupuju ke stránce s PHP nebo bez něj.
Aktualizoval jsem pouze software. Skripty zůstaly navlas stejné. Fungovaly předtím cca půl roku. Pokud jde o mod_rewrite
, nic takového nepoužívám.
To by něco znamenalo, pokud by to nebylo PHP. S PHP si ale člověk nemůže být nikdy jistý, bohužel. Zvlášť když jste aktualizoval i PHP, tam co verze, to originál…
Provedeno. Přepisování nepoužívám. Mám hned několik virtuálních hostů se statickými stránkami. Bohužel taktéž nefungují. Dopadne to stejně, ať přistupuju ke stránce s PHP nebo bez něj.Nemůžete mít zapnuté nějaké include nebo něco podobného? I z toho, že jsou všechny procesy ve stavu R bych tipoval, že ty procesy na nic nečekají, ale opravdu se snaží něco (cyklicky) načítat. Zkusil jste se připojit k serveru přímo telnetem a podívat se, jestli alespoň něco odpoví?
telnet server 80 GET / HTTP/1.0 Host: virtualhost.example.com <Enter> <Enter>
Jádro jsem updatoval až po Apache. (Právě kvůli takovému podezření.) Jenže před updatem i po něm to bylo stejné. Příkaz top ukazuje, že zamrzlé procesy jsou ve stavu R. Z nějakého důvodu je ovšem nelze zabít ani pomocí kill -9.
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 4035 nobody 25 0 21228 8372 2276 R 99.4 2.9 0:25.39 httpd
S každým dalším HTTP dotazem přibude další httpd. (Až do maximálního počtu procesů, které smí httpd vytvářet.) Procesor si mezi sebou dělí spravedlivě, avšak bezúčelně.
Předejdu i další možné otázce: Memtest jsem nechal běžet 9 hodin. Nenašel žádnou chybu.
R
a nezlikviduje ho 'kill -9
', pak IMHO není problém v tom procesu.
Možná není problém v procesu, ale pořád nevím, v čem by být mohl. Ty procesy jsou potomky jednoho httpd - nejspíš toho, který se spustil první. Ten se nezablokuje. Při restartu napřed zkouší zabít své zablokované potomky a zapisuje to do logu. Třikrát pošle SIGTERM. Když to nepomůže, pošle SIGKILL. Jenže ani ten nepomůže. (Tak prostě zůstanou běžet a přežijí dál.) (Zabíjení pomocí kill
samozřejmě taky nepomáhá.)
Je to pravda. Týká se to i Courier-MTA, jak jsem zjistil. Problém není v Apachi, ale v novém distribučním kernelu. Vždy o důvod víc, proč si zkompilovat vlastní. Teprve během dneška jsem našel tohle. (Jinak bych tu s tím neotravoval.)
Zkusím zkompilovat vlastní kernel nebo sehnat starší a pak se uvidí. Předpokládám, že tím problém prostě zmizí.
Chyba v kernelu je to poslední, na co bych býval vsadil, ale asi už to tak bude...
Problém není v Apachi, ale v novém distribučním kernelu. Vždy o důvod víc, proč si zkompilovat vlastní.
To není tak jednoznačné. Distribuční jádra jsou obecně testována více než vanilla a při současném vývojovém modelu řady 2.6 to platí dvojnásob (zejména u 2.6.x). Samozřejmě se může stát, že distribuční patche zavlečou do jádra chybu, která ve vanilla stromu nebyla, ale obráceně je to pravděpodobnější.
Konkrétně u ArchLinuxu bych nesázel na to, že distribuční jádra budou lepší než Vanilla...
Násilně vypnut byl mnohokrát. Pak byl vždy nabootován z CD a proveden e2fsck na všechny oddíly.
PHP skripty neobsahovaly nic nekompatibilního nebo zastaralého. Kromě toho nefungují ani statické stránky.
Asi ten downgrade budu muset udělat, i když se toho poněkud děsím... Nic jiného prostě nezbývá. Jenže kdyby to byl opravdu nový problém s Apachem, už by toho byl plný Google... Jenže ono pořád nic.
Tiskni
Sdílej: