Byly zveřejněny výsledky průzkumu (infografika) mezi uživateli FreeBSD.
Na konferenci DevConf.CZ 2024 je na stánku Furi Labs prezentován linuxový telefon FuriPhone FLX1. Jeho cena 499 dolarů.
Bylo vydáno Eclipse IDE 2024-06 aneb Eclipse 4.32. Představení novinek tohoto integrovaného vývojového prostředí také na YouTube.
Proton, tj. fork Wine integrovaný v Steam Play a umožňující v Linuxu přímo ze Steamu hrát hry určené pouze pro Windows, byl vydán ve verzi 9.0-2 (𝕏). Přehled novinek se seznamem nově podporovaných her na GitHubu. Aktuální přehled her pro Windows běžících díky Protonu také na Linuxu na stránkách ProtonDB.
Po roce od vydání verze 15.5 bylo vydáno openSUSE Leap 15.6. Přehled novinek v nejnovější verzi této linuxové distribuce v oznámení o vydání a v poznámkách k vydání.
Byla vydána nová verze 256 správce systému a služeb systemd (GitHub). Nově mimo jiné s run0 jako alternativou k sudo.
Společnost Oracle oznámila spolupráci s Google Cloudem, OpenAI a Microsoftem.
Zítra začne v Brně na FIT VUT třídenní open source komunitní konference DevConf.CZ 2024. Vstup je zdarma, nutná je ale registrace. Na programu je celá řada zajímavých přednášek, lightning talků, meetupů a workshopů. Přednášky lze sledovat i online na YouTube kanálu konference. Aktuální dění lze sledovat na Matrixu, 𝕏 nebo Mastodonu.
Google Chrome 126 byl prohlášen za stabilní. Nejnovější stabilní verze 126.0.6478.55 přináší řadu oprav a vylepšení (YouTube). Podrobný přehled v poznámkách k vydání. Opraveno bylo 21 bezpečnostních chyb. Vylepšeny byly také nástroje pro vývojáře.
Byl vydán Mozilla Firefox 127.0. Přehled novinek v poznámkách k vydání, poznámkách k vydání pro firmy a na stránce věnované vývojářům. Řešeny jsou rovněž bezpečnostní chyby. Nový Firefox 127 je již k dispozici také na Flathubu a Snapcraftu.
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?