Americký výrobce čipů Nvidia získal od vlády prezidenta Donalda Trumpa souhlas s prodejem svých pokročilých počítačových čipů používaných k vývoji umělé inteligence (AI) H20 do Číny. Prodej těchto čipů speciálně upravených pro čínský trh by tak mohl být brzy obnoven, uvedla firma na svém blogu. Americká vláda zakázala prodej v dubnu, v době eskalace obchodního sporu mezi oběma zeměmi. Tehdy to zdůvodnila obavami, že by čipy mohla využívat čínská armáda.
3D software Blender byl vydán ve verzi 4.5 s prodlouženou podporou. Podrobnosti v poznámkách k vydání. Videopředstavení na YouTube.
Open source webový aplikační framework Django slaví 20. narozeniny.
V Brestu dnes začala konference vývojářů a uživatelů linuxové distribuce Debian DebConf25. Na programu je řada zajímavých přednášek. Sledovat je lze online.
Před 30 lety, tj. 14. července 1995, se začala používat přípona .mp3 pro soubory s hudbou komprimovanou pomocí MPEG-2 Audio Layer 3.
Výroba 8bitových domácích počítačů Commodore 64 byla ukončena v dubnu 1994. Po více než 30 letech byl představen nový oficiální Commodore 64 Ultimate (YouTube). S deskou postavenou na FPGA. Ve 3 edicích v ceně od 299 dolarů a plánovaným dodáním v říjnu a listopadu letošního roku.
Společnost Hugging Face ve spolupráci se společností Pollen Robotics představila open source robota Reachy Mini (YouTube). Předobjednat lze lite verzi za 299 dolarů a wireless verzi s Raspberry Pi 5 za 449 dolarů.
Dnes v 17:30 bude oficiálně vydána open source počítačová hra DOGWALK vytvořena v 3D softwaru Blender a herním enginu Godot. Release party proběhne na YouTube od 17:00.
McDonald's se spojil se společností Paradox a pracovníky nabírá také pomocí AI řešení s virtuální asistentkou Olivii běžící na webu McHire. Ian Carroll a Sam Curry se na toto AI řešení blíže podívali a opravdu je překvapilo, že se mohli přihlásit pomocí jména 123456 a hesla 123456 a získat přístup k údajům o 64 milionech uchazečů o práci.
Byla vydána (𝕏) červnová aktualizace aneb nová verze 1.102 editoru zdrojových kódů Visual Studio Code (Wikipedie). Přehled novinek i s náhledy a videi v poznámkách k vydání. Ve verzi 1.102 vyjde také VSCodium, tj. komunitní sestavení Visual Studia Code bez telemetrie a licenčních podmínek Microsoftu.
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.