Databáze DuckDB (Wikipedie) dospěla po 6 letech do verze 1.0.0.
Intel na veletrhu Computex 2024 představil (YouTube) mimo jiné procesory Lunar Lake a Xeon 6.
Na blogu Raspberry Pi byl představen Raspberry Pi AI Kit určený vlastníkům Raspberry Pi 5, kteří na něm chtějí experimentovat se světem neuronových sítí, umělé inteligence a strojového učení. Jedná se o spolupráci se společností Hailo. Cena AI Kitu je 70 dolarů.
Byla vydána nová verze 14.1 svobodného unixového operačního systému FreeBSD. Podrobný přehled novinek v poznámkách k vydání.
Společnost Kaspersky vydala svůj bezplatný Virus Removal Tool (KVRT) také pro Linux.
Grafický editor dokumentů LyX, založený na TeXu, byl vydán ve verzi 2.4.0 shrnující změny za šest let vývoje. Novinky zahrnují podporu Unicode jako výchozí, export do ePub či DocBook 5 a velké množství vylepšení uživatelského rozhraní a prvků editoru samotného (např. rovnic, tabulek, citací).
Byla vydána (𝕏) nová verze 7.0 LTS open source monitorovacího systému Zabbix (Wikipedie). Přehled novinek v oznámení na webu, v poznámkách k vydání a v aktualizované dokumentaci.
Organizace Apache Software Foundation (ASF) vydala verzi 22 integrovaného vývojového prostředí a vývojové platformy napsané v Javě NetBeans (Wikipedie). Přehled novinek na GitHubu. Instalovat lze také ze Snapcraftu a Flathubu.
Společnost AMD na veletrhu Computex 2024 představila (YouTube) mimo jiné nové série procesorů pro desktopy AMD Ryzen 9000 a notebooky AMD Ryzen AI 300.
OpenCV (Open Source Computer Vision, Wikipedie), tj. open source multiplatformní knihovna pro zpracování obrazu a počítačové vidění, byla vydána ve verzi 4.10.0 . Přehled novinek v ChangeLogu. Vypíchnout lze Wayland backend pro Linux.
Při startu serveru dojde k automatickému připojení šifrovaného oddílu s btrfs. Klasicky standardní cestou, nic extra. Problém je, že dvě služby se v rámci systemd spustí dřív, než je partition namapována. Těmi službami je minidlna a nfs-kernel-server. Obě hlásí nedostupnost adresáře, který je na dané partition. Služby se tedy nespustí. V konfiguraci služeb není žádný problém, stačí je restartovat a vše šlape.
Unity zmíněných služeb nejsou nijak modifikovány, vše by default. Z nějakého důvodu se neaplikuje "After=local-fs.target". Distribuce Debian 11, origo kernel, stable větev.
Jedná se opravdu o hloupost a není to bug, ale fce.
Zdar Max
PS: Znovu připomínám, že problém je dávno vyřešen, ale přišlo mi to celkem zajímavé jako kvízek.
Tiskni Sdílej:
legitimni, kdyz lide vyjadri nazor k systemd takovym tim zkratkovitym zpusobem - totiz ze to nazvou srackouLegitimní to není, systemd není sračka, protože přináší jednoznačné benefity oproti původnímu SysV init (nebudu znovu vyjmenovávat).
jsem programoval jeden init-script asi tak jednou za 5 let. U systemd budu tedy muset editovat jedenkrat za 5 let nejaou unit. Uspora ??Úspora je v tom, že ten unit poběží všude (bude-li mít správně nastavené a standardní dependencies) a nebudeš muset pokaždé vymýšlet číslo, které mu přiřadit, aby na daném počítači fungovalo. Což u pár počítačů asi nebude velký problém, ale vývojář software nezávislého na distribuci nemá naprosto představu, na jak obskurním setupu může software běžet. PS: Já pořád nechápu tu averzi k systemd, co je s těma lidma? Kdysi jsem psal process manager (ještě v dobách před systemd) a deklarace pořadí byla dána závislostmi - nikdy by mě nenapadlo dělat jej přes čísla. Jako chápu, že u SysV initd kdysi dávno někdo zvolil čísla, ale obhajovat to jako lepší řešení, když dnes vedle sebe postavím číselné a deklarativní, to už musí být něco sakra špatně...?
PS: pokud ti nevyhovuje journalctl, používej rsyslog a logrotate, nic ti v tom nebráníKdyž nebude mít funkční journal s dostatečnou historií, tak kdykoli udělá
systemctl start mojeslužba
(které mimochodem nejde debugovat co vlastně přesně spouští, aby to člověk mohl zkusit ručně nebo se prostě podíval co se sakra děje) a nenaběhne to, tak si nemá jak vypsat, co to řeklo na stdout a stderr než to umřelo, ne?
StandardOutput=append:/var/log/app/app.log StandardError=append:/var/log/app/error.lognebo:
StandardOutput=syslog StandardError=syslog #StandardError=inherit SyslogIdentifier=<your program identifier> # without any quote SyslogFacility=local4Nebo pak jak jsem zmínil, tak globálně přesměrovat journald:
nano /etc/systemd/journald.conf ... [Journal] ... ForwardToSyslog=yes MaxLevelSyslog=debug ...Prostě možností je spousta. Buď lze přesměrovat jen něco, nebo všechno, nebo nezapisovat do journald, ale rovnou do souboru apod.
Obecně není s funkčností problém, takže někde asi děláš chybu.To není pravda, například neskipnutelné (e.g. zmáčknutím Ctrl+C na konzoli) čekání při bootu nebo absence základní funkčnosti v journalu jsou normálně oficiální vlastnosti.
journalctl
, ale musis zadat konkretny namespace (ako parameter).
[1] https://github.com/poettering/systemd/commit/cc4df240559aa56407ca0a0c5d2abf635b5ba477
- Pretoze je to proti filozofii Linuxu(zbytek přeskočím) Co přesně je na tom proti filozofii Linuxu? "Filozifií Linuxu" je nastartovat systém a pustit klíčové procesy po startu systému. To dělá initd i systemd, systemd řekněme spolehlivěji a efektivněji. Ve skutečnosti, funkcionalita systemd by šla zjednodušit na to, co dělá initd, ale stejně to nikdo neudělá, protože se nikdo nechce vracet o desítky let zpátky. Stejně jako nikdo nejde zpátky do dob kernelu 2.0.x , přestože byl jednoduchý a každá část dělala přesně jednu věc, na kterou byla určena - jednoduše byl neefektivní... Byl devfs proti filozofii Linuxu? Jsou GPU drivery v kernelu proti filozofii Linuxu? PS: Nechcu spadnou do flamewar. Je to jenom reakce na termín "filozofie Linuxu" a jeho ohýbání pro účely vlastní argumentace.
To dělá initd i systemd, systemd řekněme spolehlivějiMinimálně než byly odladěné různé problémy tak to s tou spolehlivostí nebylo moc slavné. Teď už jsem naštěstí dlouho na problém nenarazil, ale pokud někdo přecházel v období kdy to ještě nebylo ready, tak má pachuť dost velkou.
Uhádnete, kde byl problém?
Že systemd je sračka?
Bol problém v tom,že After=
určuje len poradie a Requires=
vyžaduje aby bol daná služba, proces už pri spustení aktívny.
systemd-analyze dot 'nfs-server.*' | dot -Tsvg > systemd.svgPřípadně pak ještě konkrétněji:
# vygeneruje jen dependency "After=, Before=" systemd-analyze dot 'nfs-server.*' --order | dot -Tsvg > systemd.svg # vygeneruje jen dependency "Requires=, RequiresOverridable=, Requisite=, RequisiteOverridable=, Wants=, Conflicts=" systemd-analyze dot 'nfs-server.*' --reuire | dot -Tsvg > systemd.svgAtd. Jde si s tím dost hrát a znázornit si jednoduše pořadí, jak by mělo docházet ke spouštění.
/etc/fstab
pre GFS2 pridat parameter x-systemd.after=drbd.service
, inac mi to stale pripajalo este pred tym, ako nabehlo DRBD.
systemctl enable
ExecStartPre=bash -c 'sleep 23s'
, pripadne zkusit vyuzit neco ze skupiny StartLimit*
Ma se na neho pockat a pak pokracovat bez ohledu na vysledek.To je otázka, zejména když to čekání je nepřeskočitelné a pak člověk teče když čeká někde v mrazu/hluku u konzole než to napočítá do 90. Manuál taky píše boot will continue without waiting, ale manuály k systemd už mají ten syndrom co mají zákony, že je prostě člověk kvůli jejich objemu nemůže znát všechny a pak ho něco překvapí. A o kousek výš se asi píše jak z toho ven (ale nezkoušel jsem to), že i nofail záznamu můžeš dát
x-systemd.before=nějaká_unita
, a pak by to mohlo počkat a až pak spustit ten NFS server nebo co to tam Max měl. Ještě teda nevím jak je to s pokusem o další spuštění - třeba by NFS server měl že když selže, tak se to po 10 sekundách restartuje, ale když se nepodaří ten mount, tak se NFS možná ani nedostane do toho failed stavu kdy by se zkoušelo otáčet (spolu se svými závislostmi). Vida, taky by to asi šlo vyřešit tím, že se NFS dá after=ten_mountpoint, ne?