Organizace Open Container Initiative (OCI) (Wikipedie), projekt nadace Linux Foundation, vydala Runtime Specification 1.3 (pdf), tj. novou verzi specifikace kontejnerového běhového prostředí. Hlavní novinkou je podpora FreeBSD.
Nový open source router Turris Omnia NG je v prodeji. Aktuálně na Allegro, Alternetivo, Discomp, i4wifi a WiFiShop.
Na YouTube a nově také na VHSky byly zveřejněny sestříhané videozáznamy přednášek z letošního OpenAltu.
Jednou za rok otevírá společnost SUSE dveře svých kanceláří široké veřejnosti. Letos je pro vás otevře 26. listopadu v 16 hodin v pražském Karlíně. Vítáni jsou všichni, kdo se chtějí dozvědět více o práci vývojářů, prostředí ve kterém pracují a o místní firemní kultuře. Můžete se těšit na krátké prezentace, které vám přiblíží, na čem inženýři v Praze pracují, jak spolupracují se zákazníky, partnery i studenty, proč mají rádi open source a co
… více »Na čem pracují vývojáři webového prohlížeče Ladybird (GitHub)? Byl publikován přehled vývoje za říjen (YouTube).
Jeff Quast otestoval současné emulátory terminálu. Zaměřil se na podporu Unicode a výkon. Vítězným emulátorem terminálu je Ghostty.
Amazon bude poskytovat cloudové služby OpenAI. Cloudová divize Amazon Web Services (AWS) uzavřela s OpenAI víceletou smlouvu za 38 miliard USD (803,1 miliardy Kč), která poskytne majiteli chatovacího robota s umělou inteligencí (AI) ChatGPT přístup ke stovkám tisíc grafických procesů Nvidia. Ty bude moci využívat k trénování a provozování svých modelů AI. Firmy to oznámily v dnešní tiskové zprávě. Společnost OpenAI také nedávno
… více »Konference Prague PostgreSQL Developer Day 2026 (P2D2) se koná 27. a 28. ledna 2026. Konference je zaměřena na témata zajímavá pro uživatele a vývojáře. Příjem přednášek a workshopů je otevřen do 14. listopadu. Vítáme témata související s PostgreSQL či s databázemi obecně, a mohou být v češtině či angličtině.
Byl vydán Devuan 6 Excalibur. Přehled novinek v poznámkách k vydání. Kódové jméno Excalibur bylo vybráno podle planetky 9499 Excalibur. Devuan (Wikipedie) je fork Debianu bez systemd. Devuan 6 Excalibur vychází z Debianu 13 Trixie. Devuan 7 ponese kódové jméno Freia.
Společnost Valve aktualizovala přehled o hardwarovém a softwarovém vybavení uživatelů služby Steam. Podíl uživatelů Linuxu poprvé překročil 3 %, aktuálně 3,05 %. Nejčastěji používané linuxové distribuce jsou Arch Linux, Linux Mint a Ubuntu. Při výběru jenom Linuxu vede SteamOS Holo s 27,18 %. Procesor AMD používá 67,10 % hráčů na Linuxu.
Zdravím,
už delší dobu se potýkám s problémem s MySQL databází, která dovedete běžet na serveru (Debian) nonstop třeba půl roku, ale pak přijde jeden nutný reboot serveru, po kterém do jednoho až třech dnů databáze spadne. Vypadá to tak, že load vzroste (ale někdy ne), databáze neodpovídá, ale zbytek běží normálně, apache atp. Při snaze mysql restartovat to vythuhne při jejím vypínání. Nezbyde tak nic jiného než restart celého serveru. Ten většinou pomohl a pak už to stabilně běželo "donekonečna" než jsem učinil časem další restart serveru.
Nějak jsem nedokázal přijít na to co by to mohlo dělat (a myslím, že ani v lozích nic nebylo). Proto jsem je vypnul. Někdo říkal, že to může být dokonce chyba logů. Navíc mi tak poklesla zátež.
Jenže teď se mi přihodila nemilá věc. Po nutném rebootu serveru jsem očekával, kdy to zase padne. A padlo... 2 dni na to. Tak jsem rebootoval server, jenže ouha. MySQL nenaběhlo a load na 30ti. Nechal jsem to 10 minut a stále nic. Opět nepomohlo nic jiného než reboot celého serveru, po kterém to už naběhlo úplně normálně.
Jenže tenhle druhý reboot mě vrátil do nechtěné smyčky a po 3 dnech to padlo zase. Opět pomohl až druhý reboot a opět čekám, kdy to zase klekne.
Teď ale co s tím. To první nenaskočení databáze po restartu serveru může být nejaká kontrola databáze po pádu a násilném restartu. Tuším, že pokud tu kontrolu přeruším dalším rebootem, příště se nespustí hned po startu, ale v záhadně načasovaném období jednoho až třech dnů (v cronu nic není). Bohužel během této kontroly databáze neběží a probíhat může taky hodinu nebo 2 a protože si to samozřejmě nenačasuje na noc, nemůžu si dovolit ji doběhnout kvůli dostupnosti serveru.
To s tou kontrolou je ale jen domněnka, možná je to něco úplně jiného. Nemáte někdo tušení co? Přemýšlím o opětovném zapnutí logů. Ale jestli mě pamět neklame, tak jsem v nich loni opravdu nic nenašel a jejich zapnutím bych snížil výkon už tak celkem vytíženého serveru na třeba i 3 dny. Když nebude na výběr, učiním tak, ale než to udělám. Nemáte někdo podobnou zkušenost nebo tušení v čem by mohl být problém?
Předem díky za případné podnětné reakce.
No nebudu se přít, moc toho o tom nevím, ale všiml jsem si, že dokonce v samotném my.cnf je uvedeno:
# Be aware that this log type is a performance killer.
#log = /var/log/mysql/mysql.log
)
Na tom něco bude :) jenže jak hledám tak hledám, pořád nemůžu najít jak bych ten log zapnul přes nějakej konfigurační soubor, aniž bych musel měnit parametry při spouštění mysql. Výstupem tuším bude /var/log/mysql.err, který je teď prázdný. Přijde mi to jako naprosto nejzákladnější záležitost, na kterou se po netu bude válet miliony návodů a ono nic.
Tiskni
Sdílej:
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz