Google Blog ČR informuje, že mobilní aplikaci Gemini a NotebookLM lze používat už také v Česku.
Byla vydána nová major verze 8 duálně licencovaného open source frameworku JUCE (Wikipedie, GitHub) pro vývoj multiplatformních audio aplikací.
Od 18. června bude možné předobjednat notebook DC-ROMA RISC-V LAPTOP II od společnosti DeepComputing s osmijádrovým 64-bit RISC-V AI CPU a s předinstalovaným Ubuntu.
Byla vydána verze 1.79.0 programovacího jazyka Rust (Wikipedie). Podrobnosti v poznámkách k vydání na GitHubu. Vyzkoušet Rust lze například na stránce Rust by Example.
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.
V minulém díle jsme se odkazovali na spoustu jednotek a vesměs se jednalo o takzvané speciální jednotky. To znamená dvě věci – není možné je přejmenovat a jejich význam je často „zadrátován“ do démona. Takže přestože se na disku vyskytují, jejich obsah může být pouhým komentářem.
basic.target – je základní jednotka, která se odkazuje na první kroky po
bootu. Systemd přidává tento cíl jako závislost pro každou runlevel.target
jednotku. Obvykle připojuje základní připojovací body (mount points), nastavuje
sockety a odkládací oddíly.
default.target – je výchozí jednotkou, která bude spuštěna při startu.
Obvykle jde o symbolický odkaz na některou z dalších jednotek jako graphical
,
nebo multi-user.target
. Parametrem systemd.unit=
můžeme systemd navést, aby
zavedl jinou jednotku než default.target
.
emergency.target – cíl pro záchranný shell, který je spouštěn po jednotce
emergency.service
. Ta obvykle spustí /sbin/sulogin
.
graphical.target – alternativa úrovně 5 (nebo 4 pokud jste uživatelem
Slackware). Ve výchozím nastavení požaduje pouze spuštěný multi-user.target
,
což je ekvivalent úrovně 3.
rescue.target – je velice podobný jednotce emergency.target
, s tím
rozdílem, že je spuštěn až po basic.target
, čili je ekvivalentem úrovně číslo
1.
sysinit.target – je ekvivalentem rcS
, nebo rcb
úrovní běhu, kde jsou
prováděný kroky nutné pro start systému. Tato úroveň není spustitelná ručně a je
spouštěna před basic.target
. Hlavním rozdílem mezi nimi je skutečnost, že
basic.target
startuje až po sockets.target
, který vytváří všechny sockety.
ctrl-alt-del.target – reakce na stisk Control+Alt+Del. Obvykle je to odkaz
na reboot.target
, čili restart systému.
halt.target – cíl spouštěný při ukončování systému.
poweroff.target – podobný cíli halt
, ale navíc vyvolá i vypnutí systému.
Tato jednotka má alternativní název runlevel0.target
.
shutdown.target – cíl, který ukončuje všechny služby při vypínání systému.
Všechny takové jednotky jsou automaticky v konfliktu s tímto cílem. Stejně tak
i LSB rc skripty, které mají být ukončeny během vypnutí stroje. Všechny
.service
jednotky jsou s tímto cílem v konfliktu.
sigpwr.target – speciální cíl, který je startován, pokud systemd obdrží
SIGPRW
, který je posílán v okamžiku, kdy selhává napájení.
systemd-shutdownd.service a systemd-shutdownd.socket je socketově
aktivovaná služba pro implementaci příkazu shutdown
. Jde čistě o interní
záležitost systemd.
*umount.target – cíl, během něhož jsou odpojeny všechny přípojné body v
systému. Ve výchozím stavu všechny jednotky typu .mount
jsou v konfliktu s
touto jednotkou.
Pro podporu LSB hlaviček init skriptů existuje několik speciálních jednotek,
takže pokud skript obsahuje Required-Start: $remote_fs
, systemd použije
odpovídající remote-fs.target
.
display-manager.service je obvykle odkaz na xdm.service
nebo podobnou.
Jde o ekvivalent $x-display-manager
, což je Debianí rozšíření LSB standardu.
local-fs.target – je automaticky přidán jako závislost všem jednotkám typu
.mount
, které odkazují na lokální přípojné body. Rovněž k LSB init skriptům s
$local_fs
závislostí.
mail-transfer-agent.target je cíl agenta pro posílání pošty (MTA). Obvykle
na něm závisí všechny jednotky nezbytné pro odesílání a přijímání pošty na
lokální stroj. Je to ekvivalent LSB cílů $mail-transfer-agent
, či
$mail-transport-agent
, opět pro kompatibilitu s Debianem.
Zbytek již jen stručně:
Systemd | LSB |
---|---|
network.target | $network |
nss-lookup.target | $named. |
remote-fs.target | $remote_fs |
rpcbind.target | $rpcbind |
rtc-set.target | $time |
syslog.target | $syslog |
swap.target | $swap |
dbus.service – speciální jednotka pro systémovou sběrnici D-BUS. Ostatní
jednotky by se měly odkazovat na dbus.target
, protože administrátor může
rozhodnout, zda bude démon spouštěn po startu, nebo jednotkou dbus.socket
na
požádání.
sockets.target – tato jednotka vytváří sockety, takže všechny jednotky, které chtějí používat odložené spuštění tuto jednotku vyžadují.
systemd-initctl.service a systemd-initctl.socket je služba a socket pro
/dev/initctl
, což je kompatibilní komunikační rozhraní pro init systém.
systemd-logger.service a systemd-logger.socket je interní logovací služba systemd. Je to výchozí závislost pro ty démony, které jsou nastaveny, aby posílali chybové zprávy do standardního chybového výstupu.
Jak je vidět z předchozího přehledu, systemd používá typy jednotek opravdu
hodně a dost často zjišťujeme, že existují dva i více různých typů stejné
jednotky. Příkladem budiž dbus – existuje dbus.socket
, dbus.service
i
dbus.target
.
Jejich význam je následující – dbus.socket
je jednotka zajišťující to, co jsme
si pojmenovali jako odložené spuštění (spuštění na požádání, nebo socketová aktivace – není mezi tím rozdíl). Vytvoří socket /var/run/dbus/system_bus_socket
a při prvním požadavku na připojení k tomuto
socketu spustí systemd komplementární dbus.service
. Ta definuje kroky, které
se mají učinit pro spuštění démona dbus.
Přestože je odložené spuštění základním principem systemd, není nijak
vynucováno a administrátor může nastavit systém tak, aby služby startovaly
okamžitě. Toto je důvodem existence jednotky dbus.target
, která je jinak až
na popisek prázdná.
Speciální adresář /lib/systemd/system/dbus.target.wants
obsahuje odkaz na
/lib/systemd/system/dbus.socket
. Ovšem v okamžiku, kdy z libovolného důvodu
zjistíme, že nám tento způsob nevyhovuje, je možné pouhou změnou symbolického
odkazu (ale tentokrát v /etc/systemd/system/dbus.target.wants
, abychom
předešli smazání při případném updatu balíčku) na dbus.service
pouštět službu
okamžitě.
Takže znovu a stručně – dbus.service
je předpis, kterak spustit a ovládat
démona D-BUS. Jednotka dbus.socket
je předpis, jak vytvořit socket služby D-BUS. V okamžiku, kdy se na něj někdo pokusí připojit, se spustí dbus.service
. A nakonec – dbus.target
je logické jméno, jehož významem je, od teď je služba D-BUS dostupná.
Systemd implementuje velice jednoduchý šablonovací systém. Existují případy, kdy máme několik prakticky totožných služeb, které by se s výhodou mohly vytvořit z jednoho souboru – šablony.
Znak @
v názvu souboru má pro systemd speciální význam, pokud totiž nenajde
požadovanou službu podle jejího jména a jméno obsahuje zavináč, zkusí se najít
soubor bez části za zavináčem.
Například uživatel požaduje akci s getty@tty2.service
. Pokud soubor daného
jména neexistuje, systemd zkusí najít getty@.service
, což je šablona pro prvně
jmenovanou službu.
Při parsování takových jednotek jsou potom k dipozici následující speciální znaky
%i
a %I
je název instance, čili tty2
v našem případě.%n
a %N
je plné jméno jednotky, čili getty@tty2
%p
a %P
je název prefixu, čili getty
Rozdíl mezi velkým a malým písmenem je v tom, že velké písmeno je neescapovaná varianta, čili zda je, či není příslušná cesta v jednotce upravena.
Klasický sysvinit definice terminálů ukládal do /etc/inittab
v podobě řádků
jako 1:2345:respawn:/sbin/getty 38400 tty1
. Systemd tento soubor nepoužívá a
má vlastní způsob konfigurace.
Všechny jednotlivé části již byly představeny, takže nezbývá, než je složit
dohromady. Pro nastavování terminálů slouží getty.target
, což je speciální
cíl, který značí, že všechny programy getty
byly již spuštěny. Soubor
/lib/systemd/system/getty@.service
s řádkem
ExecStart=-/sbin/agetty %I 38400
je šablona, kterou stačí přidat do příslušného getty.target.wants
adresáře.
Nejlepším způsobem, jak to zařídit, je vytvořit symbolický odkaz z
/lib/systemd/system/getty@.service
do
/etc/systemd/system/getty.target.wants/getty@ttyX.service
.
Potom stačí ověřit, že se multi-user.target.wants/
odkazuje na getty.target
,
čili terminály budou v tomto cíli spuštěny.
V případě, že potřebujeme změnit počet terminálů, není pak nic jednoduššího,
než vytvořit nový odkaz getty@ttyX.service
. A pokud méně, potom zase nějaký z
nich smazat. Po změně je třeba znovu načíst strom závislostí příkazem
# systemctl daemon-reload
A potom spustit, či zastavit patřičnou službu
# systemctl start getty@tty9.service # systemctl stop getty@tty6.service
Mimochodem, důvodem, proč tak moderní (ve smyslu používající nejnovější
technologie) systemd vyžaduje ruční načtení konfigurace je takový, že
standardní jaderné inotify
trpí problémem souběhu (vizte
RedHat bug 615527) – nové rozhraní fanotify
může tento problém vyřešit.
Protože systemd podporuje odložené spuštění, nastavení typické distribuce pak
dopadne tak, že budeme mít foobar.socket
i foobar.service
, čili služba
foobar bude spouštěna na požádání po tom, co dojde k prvnímu požadavku.
Ovšem to může být z mnoha důvodů problém. Odložené spuštění nemá smysl v případě, že jde o hlavní službu našeho počítače – proč spouštět webový server až po prvním požadavku, když víme, že tento počítač bude sloužit jako web server. Navíc se takový požadavek nemusí mít rád s enterprise prostředím, kdy se dotyčná služba může startovat tak dlouho, že dojde k vypršení požadavku, který ji nastartoval.
Řešení je přímočaré, stačí udělat odkaz z foobar.service
do příslušného
.target.wants
adresáře a při spuštění daného cíle se nastartuje patřičná
služba.
Problém může být též opačný – nainstalujeme balíček, který spouští službu na požádání – například ftp server. V tomto případě neexistuje způsob, jak přes systemctl
zakázat spuštění služby, disable
funguje pouze pro .service
jednotku. Řešením je vymazat .socket
jednotku a to vytvořením odkazu /etc/systemd/system/foo.socket
na /dev/null
. Tím přestane daná jednotka pro systemd existovat.
Tento díl jsme zjistili vše o speciálních jednotkách a vysvětlili si rozdíl mezi jednotkami
.service
, .socket
a .target
. Dále jsme se seznámili s
jednoduchým šablonovým systémem. Důležitým tématem byl rovněž způsob, jak měnit
závislosti mezi jednotkami prostřednictvím adresářů .wants
.
Následující díl představí přímo jednotky systemd, jejich syntax a možnosti.
Nástroje: Tisk bez diskuse
Tiskni Sdílej:
Taky děkuji autorovi za super článek a zajímavé počtení. Docela se těším, až můj Gentoo systém poběží na systed (ačkoli zatím jsem si nenašel čas a bezpečný způsob jak to otestovat ).
Hlavně bych se ale chtěl zeptat na dvě věci:
existuje (nebo se plánuje) podpora uživatelské konfigurace pro systemd? Např. pro některé výpočty co provádím bych si rád nastartoval 'memcached' daemona (socketovou aktivací). Ne systémově, ale jen pro mě jako obyč. BFU uživatele.
Podobně třeba mountování síťových úložišť. Zase bych chtěl, aby se úložiště připojilo pokud na něj přistoupím (v zadané cestě, ať už někde v /mnt/ nebo /home/ja/) a mohl jsem z něj číst jen já (nakonec zadávám svoje heslo ). Tady je samozřejmě trochu problém, jak se dostat k heslu - systemd by jej musel získat, např. přes dbus, dotazem na uživatele; tj.
přistoupím k mountpointu -> systemd se jej pokusí připojit ale nezná heslo -> vyžádá jej (nějak, lze si představit několik řešení) přes dbus -> objeví se mi KDE/Gnome/[...] dialog "Zadejte heslo pro připojení ..." -> zadám heslo -> systemd připojí adresář -> mám k dispozici data.
Nejsem vůbec náročný, ale možná je to už vyřešeno ...
existuje v systemd podpora pro nahrávání jaderných modulů na požádání (podobně jako u socketové aktivace)?Na to není potřeba systemd. To umí kernel ve spolupráci s udev. Kernel modul definuje MODULE_ALIAS_{CHAR,BLOCK}DEV, při instalaci modulů se sestaví seznam /lib/modules/$VERZE/modules.devname a podle něj udev vytvoří soubory zařízení. Jakmile na takový soubor někdo přistoupí, vyvolá to načtení modulu.