Rozdíly

Zde můžete vidět rozdíly mezi vybranou verzí a aktuální verzí dané stránky.

--- skoleni:sprava_uzivatelu_a_sluzeb [2018/10/07 14:35] – procesy 1/2 - +man pages, some cosmetic vbendel
+++ skoleni:sprava_uzivatelu_a_sluzeb [2022/11/14 11:26] (aktuální) – upraveno mimo DokuWiki 127.0.0.1
@@ Řádek 1: / Řádek 1: @@
-====== Nástřel ======
- * Uživatelé
-   * Má nějaký název (např. teď jste přihlášeni za uživatele "skoleni")
-   * Může mít i delší jméno nebo popis (gecos)
-   * Má domovský adresář
-   * Uživatelů ja na každém systému několik
- * Skupiny
-   * Skupina má název
-   * Každý uživatel je součástí alespoň jedné skupiny
-   * Může být (a zpravidla bývá) součástí skupin více
- * Identifikátory
-   * Uživatelé mají UID
-   * Skupny mají GID
-   * Uživatelé jsou tudíž asociováni se seznamem GID
-   * Názvy jsou pro jednodušší použití a identifikaci (syntactic sugar), ale hlavní je ID
- * Jak je to uložené v systému
-   * Vypsat /etc/passwd a /etc/group
-   * Jsou tam vsechny veci o kterych jsme se bavili (uid, gid, home, atd.)
-   * Všimli jste si něčeho zajímavého?
- * Zajímavosti s vysvétlením (strucnym)
-   * root - administrátor
-     * nejen názvem, ale má speciální práva
-     * UID 0
-   * Uzivatel "skoleni" ma UID 1000
-   * Spousta uzivatelu s UID <1000 (systemovi)
- * Příkazy
-   * Soubory které jsme si vypsali, tak se zásadné needitují ručně (stačí malá chyba a už se nepřihlásíte)
-   * id, id <username>, id <uid> (v prikladech zkusit roota)
-   * useradd (nefunguje, vypise to chybu)
-   * prepnout na roota (rozdil mezi `su` a `su -`)
-   * useradd
-   * passwd (nastavit mu nejake heslo)
-   * otevrit novou zalozku v teminalu a tam se prepnout (su -) na noveho uzivatele
-   * id
-   * passwd za uzivatele
-   * zpet v prvni zalozce (za roota)
-   * groupadd
-   * usermod (pridat grupu uzivateli, bacha na rozdil mezi `-G` a `-a -G`)
-   * v druhe zalozce (za noveho uzivatele)
-   * id (neni v nove grupe, vysvetlit, ze se to aplikuje az po prihlaseni)
-   * Jak zrušit uzivatele
-     * userdel - používat opatrně, nesmaže všechno co uživatel vlastnil
-     * raději e.g. `chage -E 0` - expirovat ho, pockat nejakou dobu a pak ho smazat pomocit userdel (s parametry pro smazani domovskeho adresare) a pomoci `find` najit vse co vlastnil a smazat (aspon zminit, ze je to dulezite pro konzistenci systemu)
-   * Pravidla pro uzivatele (politiky)
-     * Soubor /etc/login.defs
-     * Minimalni/maximalni cas platnosti hesla, atd.
-     * Lze pro konkretniho uzivatele menit pomoci chage
- * Práva
-   * Znovu si vypíšeme soubory /etc/{passwd,group}
-   * Nikde není uložené heslo
-   * Vypíšeme /etc/shadow
-   * Abysme vytvořili uživatele, tak jsme se museli přepnout na roota, on je totiž vlastníkem těch souborů
-   * ls -l /etc/{passwd,group,shadow}
-   * "root root" je vlastník uživatel a vlastník skupina
-   * co je ten řetězec na začátku řádku (např. rw-r--r--)
-     * vysvetlit zakladni prava (rwx), zatim vynechat rozdily mezi soubory a adresari
-     * **tady bude v prezentaci kratky kahoot, ktery navede na to, ze si muzeme zmenit heslo, ale pritom nemame pravo zapisovat do toho souboru kde je ulozene**
-     * vysvetlit setuid, setgid, sticky bit
-     * vysvetlit rozdily mezi adresari a soubory (tohle bude muset byt nejspis spojene s predchozim bodem, samostatne to asi nebude davat smysl)
-   * Priklady prav na adresarich
-     * /tmp (sticky bit na adresari)
-     * /home (chybi r i x pro others)
-       * mozna rict, ze kdyz uzivatel A rekne uzivateli B aby si od nej precetl neco z /home/A/soubor.txt, tak pak na /home/A staci aby B mel x a na ten soubor.txt staci aby mel r
-   * ACL
-     * existuji nejake ACL
-     * {get,set}facl
-     * priklady:
-       * povoleni vice ruznych skupin
-       * povoleni ruznych lidi co nejsou v nejake skupine
-       * dynamicnost (muzu pridelavat/oddelavat uzivatele co maji nekam pristup aniz bych jim musel vytvaret skupiny, pridelavat je tam, oddelavat a vsechny uzivatele odhlasovat/prihlasovat
-       * konkretni priklady:
-         * neco kde consolekit pridava prava lokalne prihlasenemu uzivateli (napada me jen /dev/video* zatim)
-====== Puvodni osnova (tipy) ======
-  * uživatelé v Linuxu (root, systémoví uživatelé, normální uživatelé)
-  * účet superuživatele (root) - jeho vlastnosti, práva a povinnosti
-    * skupina wheel
-    * /etc/sudoers
-  * soubory /etc/passwd, /etc/shadow a /etc/login.defs
-    * UID, GID, EUID, EGID, SETUID (prijit na to pres to jak passwd funguje)
-  * vytváření uživatelů (CLI)
-  * mazání uživatelů (CLI)
-  * nastavování vlastností uživatelům
-    * expirace hesel
-    * expirace účtů (chage/usermod)
-    * domovský adresář, důsledky absence domovského adresáře
-    * přihlašovací shell, /sbin/nologin
-    * co si mohou nastavit sami uživatelé, co může jen root
-  * alternativní způsoby správy uživatelů (GUI, Cockpit, ...)
-  * Skupiny
-    * funkce a vlastnosti
-    * vytváření a mazání
-  * Unixová práva v systému
-    * co jsou to práva a proč jsou důležitá?
-    * co to je vlastnictví?
-    * práva vlastníka, skupiny a ostatních
-    * čtení, zápis, spouštění
-    * setuid bit, sticky bit
-  * Nastavování práv
-    * nastavení vlastnictví (chown)
-    * nastavení práv ("chmod 755" i "chmod u+rwx")
-    * nastavení setuid ("chmod 4755" i "chmod u+s")
-    * nastavení setgid ("chmod 2755" i "chmod g+s", bacha na rozdil "0755" a "00755")
-    * sticky bit ("chmod 1777 dir" a "chmod +t dir" )
-    * Tabulečku na efekty
-    * Práva na <code>/tmp</code> a proč tak fungují
-  * Rozšířená práva (ACL)
-    * Jak fungují rozšířená práva? Jak se doplňují se standardními právy?
-    * Zobrazení ACL práv (getfacl)
-    * Nastavení ACL práv (setfacl)
-    * Zmínit pristup víc skupin
 ====== Správa užívateľov ======
 Existencia a potreba užívateľských účtov je jedným z fundamentálnych predpokladov systémov odvodených z UNIXu. Užívateľské účty tvoria spolu so skupinami bázu pre kontrolu riadenia prístupu k zdrojom (angl. //resource access control//).
@@ Řádek 139: / Řádek 21: @@
 Systémoví užívatelia sú takí uživatelia, ktorí majú typicky jeden dedikovaný
 účel, pre ktorý existujú, napr. beh webserveru a jeho právomoci
-(viac o systémových právach v kapitole !!!**<interny_odkaz_na>Práva**!!!) budú obmedzené na užívateľa
+(viac o systémových právach v kapitole [[skoleni:sprava_uzivatelu_a_sluzeb#prava_v_linuxu|Práva]]) budú obmedzené na užívateľa
 //**apache**//. Ako neskôr uvidíme, nie je spravidla taktiež možné sa za nich prihlásiť.
@@ Řádek 264: / Řádek 146: @@
   * ''gpasswd'' (8)
-===== Príkazy na správu užívateľov =====
+===== Spravujeme užívateľov =====
 V predchádzajúcich sekciách sme získali základné povedomie o užívateľoch a
 skupinách. Nadobudnuté poznatky teraz využijeme v praktických ukážkach správy
@@ Řádek 461: / Řádek 343: @@
 === Odstránenie účtu ===
 Hoci na sa na prvý pohľad môže zdať, že zmazať účet je triviálnou operáciou,
-nie je tomu celkom tak a treba k tomu pristupovať s maximálnou rozvahou, inak hrozí, že zanecháme systém v nekonzistentnom stave, napr. pokus o zmazanie účtu spolu s domovským adresárom môže ovplyvniť aj iných užívateľov, ktorí mohli domovský adresár **zdieľať!** Ďalším problémom mazania účtov sú súbory, ktoré po danom užívateľovi zostali a ktoré je nutné dodatočne dohľadať a zmazať, nakoľko userdel zmaže iba domovský adresár, užívateľský mailový inbox a skupinu s rovnomenným názvom. Preto dopredu zvážme, či nie je pre nás výhodnejšie účet expirovať. Ak sme sa predsa rozhodli účet a všetko s ním súvisiace zmazať, nezabudnime najprv účet expirovať, zabezpečiť, že daný užívateľ je odhlásený a že domovský adresár, skupina a mailový inbox **nie sú** zdieľané s inými užívateľmi. Následne užívateľa zmažeme:
+nie je tomu celkom tak a treba k tomu pristupovať s maximálnou rozvahou, inak hrozí, že zanecháme systém v nekonzistentnom stave, napr. pokus o zmazanie účtu spolu s domovským adresárom môže ovplyvniť aj iných užívateľov, ktorí mohli domovský adresár **zdieľať!** Ďalším problémom mazania účtov sú súbory, ktoré po danom užívateľovi zostali a ktoré je nutné dodatočne dohľadať a zmazať, nakoľko ''userdel'' zmaže iba domovský adresár, užívateľský mailový inbox a skupinu s rovnomenným názvom. Preto dopredu zvážme, či nie je pre nás výhodnejšie účet expirovať. Ak sme sa predsa rozhodli účet a všetko s ním súvisiace zmazať, nezabudnime najprv účet expirovať, zabezpečiť, že daný užívateľ je odhlásený a že domovský adresár, skupina a mailový inbox **nie sú** zdieľané s inými užívateľmi. Následne užívateľa zmažeme:
 <code>
@@ Řádek 474: / Řádek 356: @@
   * ''userdel'' (1)
-===== Príkazy na správu skupín =====
+===== Spravujeme skupiny =====
 V tejto sekcii si ukážeme ako pridať do systému novú skupinu a ako si za
 bežného užívateľa zmeniť primárnu skupinu. Ostatné operácie nad skupinami sú
@@ Řádek 516: / Řádek 398: @@
   - nové nariadenie školy taktiež prikazuje z bezpečnostných dôvodov meniť študentom heslo každý mesiac
   - //honza// a //pepa// patria do skupiny ''fyzika''
-  - //honza// sa rozhodol prestúpiť z matematického do fyzikálneho krúžku,  vykonajte príslušnú zmenu v skupinách
+  - //honza// sa rozhodol prestúpiť z fyzikálneho do matematického krúžku,  vykonajte príslušnú zmenu v skupinách
   - //pepa// je krutoprísny a rád by si nastavil login shell na ''/sbin/nologin''
   - //petr// prestúpil na inú školu, preto je treba jeho účet bezpečne invalidovať, a následne zmazať, vykonajte všetky potrebné kroky
@@ Řádek 736: / Řádek 618: @@
 ===== Procesy =====
-Procesy v Linuxe sú vlastne presne také, ako je v dnešných výpočtových systémoch bežné a dá sa očakávať.
+Termínom proces rozumieme akýkoľvek **bežiaci** program (program, ktorý nebeží nie je nič iné ako súbor inštrukcií uložených na disku) v systéme. Je to teda nejaká abstrakcia, ktorá má určité charakteristiky, medzi ktoré patrí jednoznačný číselný identifikátor **PID** (angl. //process ID//), virtuálne namapovaný **pamäťový priestor** (angl. //virtual address space//), stav procesu, rôzne behaviorálne vlastnosti ako zdieľanie zdrojov, obsluha signálov, komunikácia s inými procesmi atď.
-Každý proces má svoj //číselný identifikátor// (process ID - **PID**),  kontinuálny, virtuálne namapovaný **pamäťový priestor** obsahujúci //zásobník, haldu, exekučný kód// a pod. Môžu zdieľať zdroje a vlastnosti, meniť //stavy//, obsluhovať signály a aj združovať sa do väčších logických skupín.
+==== Vytvorenie procesu ====
+Nové procesy vznikajú výlučne **kopírovaním** existujúceho procesu, ktorý vytvorí nový proces ako svojho potomka. Je to dôsledok toho, že procesy sú v Linuxe usporiadané do stromovej hierarchie, kde budeme v neskôr praktických ukážkach pozorovať vzťah **rodič-potomok** a uvidíme jeho význam. To znamená, že v systéme existuje proces, ktorý je nadradený všetkým procesom, jeho **PID == 1** a historicky sa nazýval //init//, ktorý pri štarte systému spušťal ďalšie skripty a služby, aby systém naštartoval do stavu, v ktorom s ním môžeme pracovať. Na väčšine významných distribúcií (vrátane Fedory) dnes túto úlohu plní //systemd//, ktoré je v porovnaní s pôvodným //init// komplexný subsystém, ktorý nám okrem iného poskytuje mechanizmy na správu ďalších služieb a o ktorom si povieme viac v neskoršej kapitole.
+Čo sa samotného vytvorenia procesu týka, po tom, čo nadradený proces vytvorí svoju identickú kópiu (systémové volanie ''fork''), tento novovytvorený proces spustí nami požadovaný program (systémové volanie ''execve''). Detailný popis toho, čo vytvorenie procesu obnáša na pozadí je nadrámec tohoto školenia a dá sa dohľadať v [[http://os-book.com/OS10/index.html|literatúre]].
+Vytvorme si teda nejaký proces, napr. príkazom ''ping'':
+<code>$ ping mojefedora.cz</code>
+Program //ping// vznikol vytvorením kópie //shellu//, v ktorom sme ho spustili. A keďže proces musí mať nejaký PID, tak to overme jednoducho príkazom ''pgrep'' v druhom terminále:
+<code>
+$ pgrep ping
+
+</code>
+V tejto kapitole sme spomenuli, že všetky procesy vytvárajú stromovú hierarchiu s reláciou **rodič-potomok**. Teraz overme, že //shell//, v ktorom sme //ping// spustili je skutočne jeho rodičom. V našom druhom terminále spustime príkaz ''pstree'' a z celého výstupu vyselektujme iba //ping// za použitia [[skoleni:zaklady_prikazove_radky#roury_pipe| '|' (pipe)]]:
+<code>
+$ pstree -p | grep ping
+|-gnome-terminal-(2038)-+-bash(2153)---ping(2633)
+</code>
+Vidíme, že náš //ping// s **PID == 2633** vznikol z nejakého //shellu// (PID == 2153), ktorý zase vznikol ako potomok programu //gnome-terminal// (PID == 2038). Príkaz ''pstree'' zobrazí úplne všetky procesy daného užívateľa (//školení//) v stromčeku. Ako cvičenie si spustite ''pstree'' samostatne bez parametrov a uvidíte, že všetky procesy majú spoločný koreň proces **//systemd(1)//**.
-Z pohľadu Linuxového kernelu je každý proces (bez rozdielu “vlákien”) iba //exekučná jednotka//, ktorá je jednoznačne definovaná prostredníctvom štruktúry ''task_struct''.\\
-Pri štarte (//boot//) sa vytvorí //iniciálny proces// (**PID 1**), ktorý následne vytvára ostatné procesy.
-==== Vytváranie ====
-Nové procesy sa vytvárajú doslova //kopírovaním// procesu, ktorý daný proces vytvára.
-Používajú sa k tomu systémové volania:
-  * ''fork()''
-    * Volajúci proces (//parent//) vytvorí nový proces (//child//), ktorý je presná kópia volajúceho procesu, vrátane miesta exekúcie.
-    * Nový proces má vlastnú kópiu pamäte, navzájom si ju s volajúcim procesom neovplyvňujú.
-  * ''clone()''
-    * Môže naviac definovať napr. zdielanie niektorých vlastností s volajúcim procesom (pamäť, PID, otvorené súbory, …).
-    * Narozdiel of //fork()//, nepokračuje na tom istom exekučnom mieste, ale spustí parametrom predanú funkciu.
-  * ''execve()''
-    * Spúšťa nový program prostredníctvom zadaného //mena súboru// a //argumentov//
 === Manuálové stránky ===
-  * ''fork'' (2)
+  * ''pgrep'' (1)
-  * ''clone'' (2)
+  * ''pstree'' (1)
-  * ''execve'' (2)
+==== Komunikácia/Interakcia s procesmi ====
+=== Úvod ===
+Komunikáciu v kontexte procesov všeobecne označujeme pojmom **medziprocesová komunikácia** (angl. //inter-process communication
+ - IPC//) a môže prebiehať na rôznych úrovniach:
+  * súbory
+  * signály
+  * správy (angl. //message passing//)
+  * sokety
+  * rúry (angl. //pipe//)
+  * zdieľaná pamäť (angl. //shared memory//)
+  * iné
+Pre potreby systémovej administrácie sa obmedzíme na **signály**, čo je špecifický druh komunikácie systémovými správami, ktoré neslúžia na prenos dát, ale naopak slúžia na kontrolu (prípadne synchronizáciu) jednotlivých procesov.
+Taká kontrola bude pravdepodobne najčastejšie spočívať v ukončení procesu, ale vo všeobecnosti plnia signály oznamovaciu funkciu pre daný proces, napr. proces sa pokúsil o neoprávnenú operáciu, nastala zmena vonkajšieho okolia (odpojenie kontrolného terminálu), vynútenie nejakej akcie alebo zmeny správania procesu. Predtým než si začneme signály skúšať je nevyhnutné o nich vedieť zopár faktov. Ku každému signálu sa viaže nejaká predvolená akcia - **obsluha** - ktorá sa vykoná akonáhle nejakému procesu signál pošleme. Tu nám pomôže manuálová stránka ''signal (7)'', kde sa dozvieme, že predvolená obsluha väčšiny signálov je ukončenie procesu. Nie vždy nám bude takáto predvolená akcia postačovať, napr. by aplikácia chcela umožniť znovunačítanie svojej konfigurácie ako akciu na signál (**SIGUSR1**). Interne si potom aplikácia zaregistruje obsluhu daného signálu, konkrétny signál si "odchytí" a obslúži sama. Naopak, väčšina aplikácií nebude chcieť obsluhovať všetky signály, len preto, aby predišli tomu, že by ich takmer každý signál ukončil, a preto aplikácie môžu signály ignorovať alebo zablokovať. Ak by sme ale mohli ignorovať úplne všetky signály, stratili by sme tak možnosť nežiadúci program násilne ukončiť. Z tohto dôvodu sa signály **SIGKILL** a **SIGSTOP** nedajú odchytiť, ignorovať a ani zablokovať, a o obsluhu (ukončenie alebo zastavenie) sa postará vždy kernel.
+=== Posielanie signálov procesom ===
+Samotné signály potom posielame procesom pomocou príkazu ''kill''. Hoci názov by mohol napovedať, že pôjde iba o "vraždenie" procesov, nie je tomu tak a my si ukážeme prácu aj s inými POSIX signálmi, konkrétne sa budeme venovať nasledovným:
+  * **SIGTERM** - nenásilné ukončenie programu
+  * **SIGKILL** - násilné ukončenie programu
+  * **SIGINT** - prerušenie z klávesnice (predvolená akcia je ukončenie)
+  * **SIGUSR1** - užívateľský signál (angl. //user-defined signal//, vyvolá nejakú užívateľskú akciu)
+  * **SIGSTOP** - zastavenie procesu (proces existuje, ale nebeží)
+  * **SIGCONT** - pokračovanie procesu zastaveného SIGSTOP (!pozor, proces bude pokračovať na pozadí)
+  * **SIGHUP** - signalizácia odpojenia kontrolného terminálu
+Syntax príkazu je veľmi jednoduchá:
+<code>
+]$ kill [-signal] <PID>
+</code>
+===SIGTERM, SIGKILL, a SIGINT===
+Pokiaľ nešpecifikujeme žiaden signál, pošle sa signál SIGTERM, na ktorý proces bežne reaguje tak, že zastaví činnosť, odstráni dočasné zdroje (napr. súbory, ak nejaké vytvoril) a skončí. To, že proces na tento signál po sebe "poupratuje" je práve tým, že SIGTERM sa dá odchytiť a obslúžiť v aplikácii a preto je dobrým zvykom túto obsluhu v aplikácii zabezpečiť, v opačnom prípade sa SIGTERM a SIGKILL budú **správať rovnako**.
+Skúsme si teda najprv SIGTERM a SIGKILL. Spustime ''ping'' v terminále a v druhom mu pošleme SIGTERM.
+<code>
+# Terminal 1
+$ ping
+# Terminal 2
+$ pkill ping
+</code>
+Proces ''ping'' podľa očakávania skončí (''pkill'' užitočná je nadstavba ''kill'', ktorá nám umožňuje špecifikovať proces menom a narozdiel od PID). Už sme si povedali o vzťahu rodič-potomok, tak pošlime SIGTERM shellu, ktorý je rodičom nášho procesu ping.
+<code>
+# Terminal 1
+$ ping
+# Terminal 2
+$ pstree -p | grep ping
+     |-bash(28628)---ping(29006)
+$ kill 28628
+</code>
+Očakávaný výsledok je, že sa nestalo vôbec nič, pretože shell, ktorý beží ''ping'' na popredí zablokoval obsluhu takmer všetkých signálov, ktorých mohol. Skúsme teda tento shell odstreliť násilne
+<code>
+$ kill -SIGKILL 28628
+</code>
+Tentokrát by mal terminál a shell, v ktorom ping bežal, skončiť. Posledný z trojice je SIGINT, s ktorým sme sa už stretli v [[skoleni:zaklady_prikazove_radky#prompt|predchádzajúcej lekcii]]. Posielať SIGTERM alebo SIGKILL procesu na popredí z iného terminálu je trochu nemotorné, a preto máme klávesovú skratku //Ctrl+C//, ktorá sa v kontexte signálov preloží do SIGINT, ktorého predvolenou akciou je taktiež ukončenie.
+===SIGUSR<X>===
+SIGUSR<X> je dvojica užívateľských signálov SIGUSR1 a SIGUSR2 (najčastejšie však SIGUSR1), ktoré by mali slúžiť na to, že užívateľ nimi dokáže vynútiť určitú akciu, ktorá môže viesť aj ku zmene správania aplikácie. Typicky by nám aplikácia týmto spôsobom umožnila znovu načítať svoju konfiguráciu za behu bez potreby jej ukončenia, a tým pozmeniť svoje správanie. My si ukážeme iný zaujímavý a jednoduchší príklad efektu tohto signálu. Použijeme k tomu príkaz ''dd'', ktorý kopíruje data zo zdroja (parameter ''if='') do cieľa (parameter ''of='').
+<code>
+# ak nepouzijem ziadne parametre, tak prikaz bude kopirovat 0 do /dev/null (tzv.sink) donekonecna
+$ dd if=/dev/zero of=/dev/null
+</code>
+My by sme ale radi vedeli, koľko dát sme takto už nakopírovali, pretože program nám v základnej konfigurácii neposkytuje žiadne štatistiky. Program ''dd'' však dokumentuje, že na SIGUSR1 nám štatistiku vráti.
+<code>
+$ dd if=/dev/zero of=/dev/null &
+[1] 30372
+# vyziadajme si statistiku
+$ kill -SIGUSR1 30372
+37224676+0 records in
+37224675+0 records out
+19059033600 bytes (19 GB, 18 GiB) copied, 32.4629 s, 587 MB/s
+</code>
+===SIGSTOP a SIGCONT===
+SIGSTOP je (ako názov napovedá) veľmi jednoznačný, proces, ktorý signál dostane je pozastavený - **neskončil**, ale ani nebeží, systém o ňom stále vie a na signál SIGCONT bude daný proces pokračovať odtiaľ kde bol pozastavený. S týmto signálom ste sa už pravdepodobne stretli, ak ste sa pokúsili spustiť na pozadí program, ktorý očakáva nejaký vstup.
+<code>
+$ cat &
+[1] 31827
+[1]+ Stopped    cat
+</code>
+Náš príkaz ''cat'' bol ihneď po spustení na pozadí pozastavený (//Stopped//). Dôvod, prečo sa tak stalo je, že proces sa pokúsil prečítať zo ''stdin'', ktorý však neukazuje na žiadny terminál, práve preto, že proces má bežať na pozadí. Systém to vyhodnotil tak, že proces zastavil, a učinil tak signálom SIGSTOP. Úplne ekvivalentne si môžeme ''cat'' spustiť na popredí a zastaviť ho explicitne. Následne sa pokúsime proces znovu obnoviť signálom SIGCONT.
+<code>
+# Terminal 1
+$ cat
+# Terminal 2
+$ kill -SIGSTOP `pgrep cat`
+# Terminal 1
+[1]+ Stopped   cat
+# Terminal 2
+# obnovme process cat
+$ kill -SIGCONT `pgrep cat`
+# Terminal 1
+[1]+  Stopped  cat
+</code>
+Náš proces ''cat'' bol okamžite po obnovení znovu pozastavený, prečo je tomu tak? Signál SIGSTOP okrem iného odpojil ''stdin'' pre daný proces a keďže ''cat'' očakáva vstup, ktorý nemá odkiaľ čítať, tak bol automaticky pozastavený, rovnako ako keby sme ho spustili na pozadí. Ako cvičenie si SIGSTOP a SIGCONT skúste na programoch, ktoré vstup nevyžadujú.
-==== Komunikácia ====
+===SIGHUP===
+SIGHUP je signál, ktorý proces dostane v prípade, ak bol jeho kontrolný terminál alebo kontrolný proces odpojený. V praxi to znamená asi toľko, že všetky programy, ktoré z daného terminálu spustím (na popredí či na pozadí) skončia v momente keď okno terminálu zavrieme. Táto reťazová reakcia je špecifická pre UNIX shell, ktorý SIGHUP odchytí a všetkým procesom, ktorých je tento shell rodičom SIGHUP prepošle. My by sme ale radi niektoré procesy bežiace na pozadí radi pred SIGHUP zachránili, urobíme to jednoducho pomocou príkazu ''nohup'':
-Naopak, keď chceme proces //zastaviť// (//zrušiť//), môžeme jednoducho použiť príkaz ''kill'':
 <code>
-]$ kill <PID>
+$ nohup ping mojefedora.cz &
+[1] 588
+nohup: ignoring input and appending output to 'nohup.out'
 </code>
-Príkaz //kill// takto vlastne pošle terminačný //signál// (''SIG_TERM == 15''), na ktorý proces bežne reaguje tak, že zastaví činnosť a skončí (pamäť uvoľní kernel).
-Všeobecne sa s procesmi bežne komunikuje prostredníctvom **signálov**.
+Ak by teraz nadradený shell dostal SIGHUP (zavrieme okno terminálu), náš proces bude stále v systéme bežať, vyskúšajte!
-Príkazom //kill// môžeme poslať v podstate aj ktorýkoľvek iný signál definovaný podľa **POSIX**.
 === Manuálové stránky ===
   * ''kill'' (1)
+  * ''pkill'' (1)
   * ''signal'' (7)
-==== Informácie a vlastnosti ====
+====Monitorovanie procesov====
-Z užívateľského prostredia (//user-space//) sa najbežnejšie získavajú informácie o existújucich procesoch pomocou príkazov: ''ps'' a ''top''.
+V predchádzajúcich sekciách sme načrtli príkaz ''pstree'', aby sme získali usporiadanie užívateľských procesov v systéme. Predtým, než sa začneme zaoberať monitorovaním procesov, ukážeme si ako získať zoznam všetkých procesov v systéme bez nutnosti vykresľovania ich vzájomných vzťahov, ako sme to videli pri ''pstree''. K tomu slúži príkaz ''ps''.
 === Príkaz ps: ===
@@ Řádek 788: / Řádek 801: @@
 ]$ ps
   PID TTY          TIME CMD
-pts/1    00:00:00 ps          <- tento prikaz “ps”
+pts/1    00:00:00 ps          <- tento príkaz “ps”
-pts/1    00:00:00 bash        <- tento terminal (bash)
+pts/1    00:00:00 bash        <- tento terminál (bash)
 </code>
   * ''ps u''
@@ Řádek 813: / Řádek 826: @@
 //Pozn.:// Procesy v hranatých zátvorkách ''[]'' sú systémové procesy (tzv. //kernel-threads//)
-  * ''ps f''
+**Pozor:** Je rozdiel medzi prepínačmi s pomlčkou ''-'' a bez, napr. ''ps -aux'' (UNIX syntax) a ''ps aux'' (stará BSD syntax), preto odporúčame adoptovať novšiu UNIX syntax, napr. ekvivalent ''ps aux'' by v UNIX syntaxi vyzeral ''ps -eF'' (niektoré stĺpčeky sa budú mierne odlišovať).
-    * Zobrazí stromovú štruktúru (prípadne existuje aj ''pstree'')
+=== Príkaz top: ===
+Príkaz ''ps'' nám poskytuje obrovské množstvo informácií o procesoch, avšak má jeden zásadný problém - ''ps'' nevypisuje štatistiky v reálnom čase, čo nás ako administrátorov zaujíma najviac. Práve preto existuje príkaz ''top'', ktorý periodicky obnovuje zobrazované dáta v reálnom čase. Existuje mnoho možností, ako upraviť //ktoré// informácie ''top'' zobrazuje, avšak my si ukážeme iba základné zobrazenie:
 <code>
-]$ ps f
+]$ top
-pts/1    Ss     0:00 bash
+top - 17:09:51 up 6 days,  8:29,  1 user,  load average: 0.95, 0.86, 0.74
-pts/1    R+     0:00  \_ ps f
+Tasks: 313 total,   2 running, 246 sleeping,   0 stopped,   0 zombie
-tty2     Sl+    0:01  \_ /usr/libexec/gnome-session-binary
+%Cpu(s):  3.0 us,  1.0 sy,  0.0 ni, 95.6 id,  0.1 wa,  0.2 hi,  0.1 si,  0.0 st
- tty2     Sl+  140:05      \_ /usr/bin/gnome-shell
+KiB Mem : 11857404 total,   511728 free,  7916376 used,  3429300 buff/cache
-tty2     Sl+   28:35      |   \_ /usr/bin/Xwayland :0 -rootless -terminate -core -listen 4 -listen
+KiB Swap:  6033404 total,  4828844 free,  1204560 used.  4494984 avail Mem
-tty2     Sl     0:06      |   \_ ibus-daemon --xim --panel disable
-tty2     Sl     0:00      |   |   \_ /usr/libexec/ibus-dconf
+  PID USER   PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
-tty2     Sl     0:00      |   |   \_ /usr/libexec/ibus-engine-simple
+user   20   0 3167768 0.983g  85780 S   3.3  8.7  91:59.69 Web Content
-tty2     Sl+  155:42      |   \_ /usr/lib64/firefox/firefox
+user   20   0 2872300 654080 160476 S   3.3  5.5  63:57.09 Web Content
-...[ atď ]...
+user   20   0 2976872 997.8m  97636 S   2.3  8.6 117:51.18 Web Content
+user   20   0 3423596 1.208g 112256 R   2.0 10.7 188:21.10 Web Content
+user   20   0 10.332g 1.188g 282536 S   1.7 10.5 160:51.69 firefox
+ user   20   0 4329020 628316 118748 S   1.0  5.3 143:07.66 gnome-shell
+user   20   0 1323312 101940  45948 S   1.0  0.9   0:45.07 virt-manager
+root   -2   0       0      0      0 S   0.3  0.0   0:38.68 i915/signal:0
+rtkit  21   1  183884     20      0 S   0.3  0.0   0:01.89 rtkit-daemon
+root   20   0 1737932  25908   8584 S   0.3  0.2   2:41.29 libvirtd
+gdm    20   0  841364  10168   5168 S   0.3  0.1   0:53.87 gsd-color
+qemu   20   0 6451560 1.199g  24940 S   0.3 10.6   1:14.55 qemu-system-x86
+user   20   0  790948 103736  31252 S   0.3  0.9  40:17.50 gnome-terminal-
+user   20   0  152008   3876   3092 R   0.3  0.0   0:00.10 top
+root   20   0  229808  10484   6636 S   0.0  0.1   1:06.37 systemd
+root   20   0       0      0      0 S   0.0  0.0   0:00.36 kthreadd
+root    0 -20       0      0      0 I   0.0  0.0   0:00.00 rcu_gp
+root    0 -20       0      0      0 I   0.0  0.0   0:00.00 kworker/0:0H
 </code>
-**Pozor:** Je rozdiel medzi prepínačmi s pomlčkou ''-'' a bez, napr. ''ps -aux'' a ''ps aux''!
+Okrem informácií o procesoch nám ''top'' v "hlavičke" zobrazuje aj ďalšie iné zaujímavé informácie:
+**Riadok 1 - uptime a load average**
+  * aktuálny čas a koľko času ubehlo od posledného štartu systému (6 dní).
+  * počet aktívnych užívateľov v systéme - koľko sedení (angl. //sessions//) existuje, dá sa overiť príkazom ''who'' (u nás 1)
+  * priemerná záťaž systému (angl. //load average//) za posledných 1 / 5 / 15 minút
+    * záťaž je vyjadrená vždy relatívne voči jednoprocesorovému systému, t.j. záťaž **1.0** na jednojadrovom CPU je plné vyťaženie, zatiaľ čo na 2 jadrách je to iba **50%** záťaž!
+**Riadok 2 - informácie o procesoch (úlohách)**
+  * celkovo 313 procesov (úloh), 2 aktuálne bežia, 246 sú v spánkovom režime, žiadne procesy nie sú pozastavené ani zombie (viď __Stavy procesu__ nižšie)
+**Riadok 3 - %CPU - percentuálne vyjadrenie koľko procesorového času využívajú rôzne procesy**
+  * **us** - čas strávený behom užívateľských procesov bez priority
+  * **sy** - čas strávený behom systémových procesov
+  * **ni** - čas strávený behom už. procesov s prioritou (viď Niceness)
+  * zvyšok je čas strávený rôznymi druhmi prerušenia, obsluhou a systémovými volaniami (viď manuálovú stránku ''top'')
+**Záhlavie procesov**:
+    * ''PR'' a ''NI'' - //priority//, //nice value//
+       * Tieto stĺpce ukazujú priority daného procesu, prípadne jeho //“niceness”// hodnotu
+    * ''S'' - //State// - Stav procesu
+      * **R** - //runnable// - Pripravený / Bežiaci
+      * **S** - //interruptible sleep// - Spiaci
+      * **D** - //uninterruptible sleep// - Čakajúci (väčšinou na dokončenie I/O)
+      * **Z** - //zombie// - Mŕtvy / Dokončený
+      * **T** - //stopped / parked// - Zastavený
+//Pozn.:// V systémoch UNIX je dobrým zvykom, aby rodičovské procesy čakali na ukončenie svojich potomkov, ak sa tak nestane, tak vznikajú tzv. //zombie// procesy - to sú také procesy, ktoré síce ukončili činnosť, no ich rodičovský proces nepotvrdil či neakceptoval ich ukončenie, a preto zostávajú uvedené v tabuľke procesov a zostanú v nej dovtedy, kým ich ukončenie niekto neprijme (ak by rodičovský proces skončil, prevezme ich automaticky //init// a ihneď prijme všetky ukončené procesy). Zombie procesy síce nespotrebovávajú výpočetné zdroje, ale blokujú dostupný PID, ak je v systéme príliš veľa zombie procesov, skonzumujú všetky možné PIDy a nebude možné vytvoriť nové procesy.
+   * ''Memory'' - Údaje o použití pamäte
+    * **VIRT** - //virtual memory space (process block)//
+      * Všetka pamäť, ktorú má process k dispozícii (zásobník, halda, exekucný kód, atď.).
+    * **RES/RSS** - //resident set size//
+      * Časť (podmnožina) VIRT, ktorá je načítaná v RAM
+      * Zvyšok može byť na disku (//swap//) alebo SHR patriace inému procesu.
+    * **SHR** - //shared memory//
+      * Časť, ktorá patrí tomuto procesu a je zároveň zdieľaná.
+    * **%MEM**
+      * Koľko percent z celkovej dostupnej pamäte proces používa (RES / RAM)
+Vďaka tomu, že ''top'' je interaktívny, tak nám umožňuje priamo s procesmi interagovať, napr. im posielať signály. Skúsme nasimulovať situáciu, kedy nám systém vyťažuje nejaký nežiadúci proces a my to chceme detekovať a proces odstrániť. K tomu budeme potrebovať balíček **stress**, ktorý dokáže simulovať vyťaženie rôznych aspektov systému.
+<code>
+$ sudo dnf install -y stress
+$ stress --cpu 1
+stress: info: [22255] dispatching hogs: 1 cpu, 0 io, 0 vm, 0 hdd
+</code>
+<code>
+$ top
+top - 22:58:25 up 12 days, 16:47,  1 user,  load average: 0.94, 0.85, 0.73
+...
+  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
+skoleni+  20   0    3880    100      0 R  99.7   0.0   0:32.49 stress
+...
+</code>
+Vidíme, že náš nežiadúci proces konzumuje takmer 100% procesorového času, vráťme sa k interaktívnemu ''top'' a postupujme nasledovne:
+<code>
+# stlacme 'k', top sa nás spýta, ktorému procesu budeme posielať signál
+...
+MiB Swap:      0.0 total,      0.0 free,      0.0 used.   8069.7 avail Mem
+PID to signal/kill [default pid = 22359]
+...
+# Enter
+# zvolme signal, my volime nasilnu cestu - sigkill
+...
+Send pid 22359 signal [15/sigterm] sigkill
+...
+# overme, ze proces 'stress' naozaj skoncil
+$ pgrep stress
+$
+</code>
 === Manuálové stránky ===
   * ''ps'' (1)
+  * ''top'' (1)
+====Pokročilé nástroje monitorovania====
+===Nástroj htop===
+Hoci je ''top'' súčasťou základnej inštalácie, v praxi sa pravdepodobne najčastejšie stretneme s používaním nadstavby ''htop'', ktorý má prijateľnejšie konfigurovateľné rozhranie v **ncurses**, ktoré nám interakciu značne uľahčuje, napr. máme možnosť sa pohybovať šípkami a selektovať tak procesy (je potrebné doinštalovať balíček **htop**).
+{{:skoleni:htop.png?direct&400|}}
+===Nástroj glances===
+''glances'' je multiplatformový ultimátny nástroj pre systémových administrátorov, ktorý združuje všetky dôležité informácie o systéme (I/O, sieťový traffic, vyťaženie CPU a MEM, stav súborového systému) kombinovanom s výstupom ''top'' v prehľadnom kompaktnom rozložení (je potrebný balíček **glances**).
+{{:skoleni:glances.png?direct&400|}}
+===Iné nástroje===
+  * ''atop''
+    * rozšírenie ''htop'', poskytuje prakticky rovnaké informácie ako ''glances'' v tradičnej "terminálovej" podobe
+  * ''nmon''
+    * komplexný monitoring v rozhraní ncurses, jednotlivé aspekty systému sa dajú vypínať a zapínať podľa potreby, výstup je v podobe grafov
+  * ''nethogs''
+    * v podstate ''top'' pre sieťovú komunikáciu, ak sa vyskytne náhly a nečakaný nárast v sieťovej komunikácii, ''nethogs'' je ten správny program na analyzovanie, ktorý proces je za to zodpovedný
+==== Priorita a "niceness" ====
+V predchádzajúcich sekciách boli spomenuté termíny ako //priorita// a //niceness//. Aby sme im porozumeli je nutné si najprv povedať niečo o plánovaní procesov.
+=== Plánovanie procesov ===
+Plánovanie je druh aktivity, ktorá nám dovoľuje multitasking, teda konkurentné vykonávanie viaverých úloh za určité časové obdobie. Plánovač je kus kernel kódu, ktorý mapuje vykonávanie úlohy (angl.//task//, to môže byť proces alebo vlákno, plánovaču je to jedno, vidí iba "úlohu") na dostupné výpočetné zdroje. To akým spôsobom sa procesy plánujú je nadrámec tohto kurzu a vyžaduje značné znalosti o [[http://os-book.com/OS10/index.html|konceptoch OS]]. Dôoležité je vedieť, že Linux nám nastaviť niekoľko typov plánovacích algoritmov (dokonca sa môžu používať rôzne algoritmy sučasne), v mnohých prípadoch budú tieto algoritmy postavené na priorite procesov.
+===Priority===
+Linux rozoznáva 140 priorít v 2 rôznych rozsahoch
+  * [1,99] pre //real-time// procesy (to sú také, ktoré uvoľnia zdroje iba ak sa nájde niekto s vyššou prioritou alebo keď skončia, taktiež majú tvrdé limity, t.j. proces musí dokončiť úlohu v stanovenom časovom okne)
+    * pre //real-time// priority platí: **1 < 99** (hodnoty sú v skutočnosti interne invertované)
+  * [100,139] - interval pre normálne (//user-space//) procesy, **100 > 139**
+**Niceness (NI)**
+  * hodnota v //user-space//, ktorá sa mapuje na skutočnú PR prioritu v kerneli, ktorá sa preloží do daného rozsahu [100,139]
+  * rozsah [-20,19] - čím menšie číslo, tým väčšia priorita procesu (štandardne však 0)
+    * NI slúži len ako váha pre plánovač, aby určil skutočnú prioritu PR
+    * na výpočet skutočnej priority sa používa vzťah:
+      <code>PR = 20 + NI</code>
+My sa teraz zamierame na to, ako hodnoty //"nice"// nastaviť. Slúži k tomu dvojica príkazov ''nice'' a ''renice'', ktoré nastavujú prioritu novým, resp. menia prioritu bežiacim procesom.
+Spustime opäť ''dd'' a nastavme rovno //nice// na 5
+<code>
+$ nice -5 dd if=/dev/zero of=/dev/null &
+$ top
+skoleni  25   5    3880     892      824 R  97.3   0.0   0:04.19 dd
+skoleni  20   0 3453680 356776 189016 S  1.0   4.4   8:19.49 gnome-shell
+...
+</code>
+Vidíme, že hoci sme spustili ''dd'' s nižšou prioritou, vyťažuje náš systém najviac. V systéme jednoducho nebeží dostatok aktívnych služieb, ktoré by potrebovali konzumovať zdroje. Teraz pridajme náš program stress a pozorujme zmenu:
+<code>
+$ stress -c 5 -m 3 -i 2 &
+$ top
+skoleni  20   0    3880    100      0 R  42.4   0.0   0:26.08 stress
+skoleni  20   0  266028  73492    268 R  41.7   0.6   0:26.35 stress
+skoleni  20   0  266028  48940    268 R  40.7   0.4   0:27.07 stress
+skoleni  20   0  266028 181468    268 R  40.4   1.5   0:25.71 stress
+skoleni  20   0    3880    100      0 R  36.8   0.0   0:24.80 stress
+skoleni  20   0    3880    100      0 R  35.1   0.0   0:25.97 stress
+skoleni  20   0    3880    100      0 R  28.5   0.0   0:25.37 stress
+skoleni  25   5  215016    892    824 R  14.9   0.0   0:04.53 dd
+skoleni  20   0 3453680 356776 189016 D  14.6   2.9 190:30.40 gnome-shell
+</code>
+Stress test nám nám úspešne vyťažuje celý systém. Skúsme niektorým z procesov ''stress'' nastaviť hodnotu //nice// vyššie než má ''dd''. Ideálne použijeme ''htop'', kde sa hodnota //nice// dá zvyšovať klávesou **F8**. Výsledok by mohol vyzerať nasledovne:
+<code>
+$ top
+  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
+skoleni  20   0  266028  64780    268 R  87.4   0.5   3:50.96 stress
+skoleni  20   0    3880    100      0 R  81.5   0.0   3:45.24 stress
+skoleni  25   5  215016    892    824 R  27.2   0.0   1:29.01 dd
+skoleni  27   7    3880    100      0 R  26.8   0.0   2:12.81 stress
+skoleni  26   6  266028 129196    268 R  25.2   1.1   2:25.45 stress
+</code>
+Program ''dd'' sa teda plánuje častejšie ako niektoré procesy programu ''stress''. Zníženie priority môžeme vyskúšať aj manuálne príkazom ''renice''
+<code>
+$ renice -n 15 11360
+$ top
+  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
+skoleni  20   0    3880    100      0 R  76.8   0.0   5:43.19 stress
+skoleni  25   5  215016    892    824 R  56.6   0.0   2:26.26 dd
+skoleni  26   6  266028 163780    268 R  44.0   1.3   3:15.84 stress
+skoleni  27   7    3880    100      0 R  42.7   0.0   2:54.81 stress
+skoleni  35  15  266028  31516    268 R  19.5   0.3   5:44.80 stress
+</code>
+Čo ak by sme naopak chceli prioritu zvýšiť (napr. pre program ''dd''):
+<code>
+$ renice 0 11376
+renice: failed to set priority for 11376: Permission denied
+</code>
+Vidíme, že na zvýšenie priority je potreba práva užívateľa **root**. Je to bezpečnostné opatrenie, aby si aplikácie samy nemohli prioritu zvyšovať a ochromiť celý systém.
+//Úloha:// Skúste zvýšiť prioritu procesu s právami roota.
 === Manuálové stránky ===
-  * ''top'' (1)
+  * ''sched'' (7)
+  * ''nice'' (1)
+  * ''renice'' (1)
-============================================================================
+===== Služby =====
+Službou v Linuxe nazývame aplikáciu (proces) alebo súbor aplikácií tvoriacich logický celok, ktoré bežia na pozadí a typicky čakajú na príchodzie požiadavky, ktoré obsluhujú (toto však nie je nutná podmienka). Existujú rôzne subsystémy (príp. softvérové kolekcie) na vytváranie a správu služieb, ale na väčšine dnešných distribúcií túto úlohu plní **systemd**. My sme //systemd// spomenuli ako predka všetkých procesov s **PID == 1**. Okrem kľúčovej úlohy //init// systému, ktorý nainicializuje celý //user-space//, plní systemd zároveň úlohu správcu služieb a systému ako takého.
-  * init proces
+====Systemd units====
-    * co je a na co to je
+Systemd nespravuje iba služby. Podobne ako plánovač v kerneli pristupuje k procesom a vláknam transparentne a jednotne ich nazýva //tasks//, systemd dokáže spravovať aj sokety, mount pointy, časovače (''systemd.timer'' ako náhrada za ''cron''), targets (target by sa dal v kontexte systemd preložiť ako referenčný bod - //checkpoint// - pre iné služby, uvidíme neskôr), a ďalšie iné entity, ktoré združene nazývame **//units//**.\\
-    * Typy, historie (velice strucne)
+//Pozn.//: všetky typy **//units//** rozoznáme podľa koncovky (//.service, .mount, .target, .timer//, atď.)
-    * systemd
-  * sluzby
+Vstupnou bránou do správy //systemd// je príkaz ''systemctl'', ktorým má obrovské množstvo zanorených príkazov, ktoré budeme v ďalších ukážkach používať.\\
-    * co je to
-    * rozdily oproti jinym procesum (pidfile, reakce na signaly - reload, reexec)
+Vypíšme si teda, aké jednotky v systéme vôbec máme.
-    * jak se to ovlada (systemctl)
+<code>
-    * start/stop
+$ systemctl list-units
-    * enable/disable (--now)
+</code>
-    * list-units
+Príkaz nám vrátil zoznam úplne všetkých jednotiek, o ktorých systemd vie. Keďže my sa venujeme službám, tak pridaním prepínača sa obmedzíme iba na služby
-    * default
-    * isolate
+<code>
-    * journalctl
+$ systemctl list-units -t service
-    * strucny priklad vytvorenia unit-file
+ UNIT                                        LOAD   ACTIVE SUB     DESCRIPTION
+  abrt-journal-core.service                 loaded active running Creates ABRT problems from coredumpctl messages
+  ...
+  upower.service                            loaded active running Daemon for power management
+  user-runtime-dir@1000.service             loaded active exited  /run/user/1000 mount wrapper
+  user@1000.service                         loaded active running User Manager for UID 1000
+  wpa_supplicant.service                    loaded active running WPA supplicant
+LOAD   = Reflects whether the unit definition was properly loaded.
+ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
+SUB    = The low-level unit activation state, values depend on unit type.
+loaded units listed. Pass --all to see loaded but inactive units, too.
+To show all installed unit files use 'systemctl list-unit-files'.
+</code>
+Ako nám povedala nápoveda na konci, zoznam obsahuje iba aktívne služby, pre vypísanie úplne všetkých služieb by sme museli pridať parameter ''--all'' (Vyskúšajte!). Ku každej službe prislúcha konfiguračný súbor v súborovom systéme, pre ich výpis by sme použili vnorený príkaz ''list-unit-files'', ktorý ponúka kompaktnejší výstup.
+<code>
+$ systemctl list-unit-files -t service
+UNIT FILE                                   STATE
+abrt-ccpp.service                           disabled
+abrt-journal-core.service                   enabled
+abrt-oops.service                           enabled
+abrt-pstoreoops.service                     disabled
+abrt-vmcore.service                         enabled
+...
+</code>
+Vďaka týmto 2 veľmi podobným príkazom môžeme pozorovať základné vlastnosti každej služby, ktoré nám hovoria niečo o ich stave:
+  * **loaded** - konfiguračný súbor služby bol vporiadku načítaný
+  * **active** - tzv.//high-level// aktivačný stav, generalizácia **sub**, pokiaľ služba neskončila s chybou, tak je vnímaná ako //active//
+  * **sub** - tzv. //low-level// aktivačný stav, popisuje, či aplikácia reálne beží, skončila úspešne alebo s chybou
+  * **enabled** - značí, že služba má bežať po štarte systému
+  * **disabled** - značí, že služba nemá bežať po štarte systému, beží teda na vyžiadanie
+Keď už sme si povedali, v akých stavoch sa služby môžu nachádzať, zobrazme si stav a bližšie informácie o konkrétnej službe (**sshd**) v danom momente. K tomu slúži vnorený príkaz ''status''
+<code>
+systemctl status sshd
+● sshd.service - OpenSSH server daemon
+   Loaded: loaded (/usr/lib/systemd/system/sshd.service; enabled; vendor preset: disabled)
+   Active: active (running) since Sun 2019-04-21 19:14:04 CEST; 44min ago
+     Docs: man:sshd(8)
+           man:sshd_config(5)
+ Main PID: 819 (sshd)
+    Tasks: 1 (limit: 4915)
+   Memory: 2.2M
+   CGroup: /system.slice/sshd.service
+           └─819 /usr/sbin/sshd -D -oCiphers=aes256-gcm@openssh.com,chacha20-poly1305@openssh.com,aes256-ctr,aes256-cbc,...
+Apr 21 19:14:04 skoleni systemd[1]: Starting OpenSSH server daemon...
+Apr 21 19:14:04 skoleni sshd[819]: Server listening on 0.0.0.0 port 22.
+Apr 21 19:14:04 skoleni sshd[819]: Server listening on :: port 22.
+Apr 21 19:14:04 skoleni systemd[1]: Started OpenSSH server daemon.
+</code>
+Z výstupu okrem iného vidíme, že služba ''sshd'' je nastavená ako //enabled//, a teda sa má spustiť po štarte systému. Skúsme teraz naštartovať nejakú službu explicitne. Na našich strojoch by mohla byť dobrým príkladom služba **httpd** (webový server), ktorý ani nebeží a ani nemá bežať po štarte systému, poďme to zmeniť. Službu štartujeme príkazom ''start''
+<code>
+(root)$ systemctl start httpd
+$ systemctl status httpd
+● httpd.service - The Apache HTTP Server
+   Loaded: loaded (/usr/lib/systemd/system/httpd.service; disabled; vendor preset: disabled)
+   Active: active (running) since Sun 2019-04-21 20:01:09 CEST; 3s ago
+</code>
+Apache server síce beží, ale po reštarte už bežať nebude, je potrebné službu povoliť (//enable//).
+<code>
+(root)$ systemctl enable httpd
+# overte, ze httpd bezi po restarte
+$ systemctl status httpd
+</code>
+//Pozn.//: My sme si ukázali, ako naštartovať a povoliť službu v 2 krokoch, v praxi sa obe operácie dajú spraviť v 1 kroku za použitia ''systemctl enable --now <service>''.
+Analogicky by sa použili opačné operácie:
+  * ''systemctl stop <service>'' - zastaví bežiacu službu
+  * ''systemctl restart <service>'' - zastaví a znovu spustí službu
+  * ''systemctl disable <service>'' - zakáže naštartovanie služby po reštarte systému
+===Manuálové stránky===
+  * ''systemd.unit'' (5)
+  * ''systemd.service'' (5)
+  * ''systemctl'' (1)
+==== Konfiguračné súbory ====
+Konfiguračné súbory služieb môžu byť v systéme uložené hneď na niekoľkých miestach:
+  * ''/etc/systemd/system'' - lokálna perzistentná konfigurácia, sem patria všetky užívateľské služby s efektom na celý systém
+  * ''/run/systemd/system'' - dočasné konfigurácie pre dané systémové sedenie
+  * ''/usr/lib/systemd/system'' a ''/usr/local/lib/systemd/system'' - konfiguračné súbory, ktoré sa nainštalovali ako súčasť nejakého balíčku, **neodporúča** sa pracovať s týmito konfiguračnými súbormi priamo
+Občas ale potrebujeme konfiguráciu nainštalovaných služieb pozmeniť podľa našich požiadavkov. Ak teda nemáme pracovať s konfiguráciami v ''/usr'' priamo, mohli by sme vytvoriť našu vlastnú identickú kópiu danej služby a používať ju namiesto tej nainštalovanej, ale asi vidíme, že to nie je zrovna efektívny prístup. Systemd nám totiž poskytuje príkaz ''edit'', ktorý dokáže meniť exitujúce konfigurácie za pomoci špeciálneho súboru, ktorý sa vytvorí automaticky ako ''/etc/systemd/system/<sluzba>.d/override.conf''.
+My si to ukážeme na príklade s ''httpd''. Ako každá iná aplikácia, aj ''httpd'' môže skončiť abnormálne (napr. neoprávnený prístup do pamäte). V kontexte //systemd// by to znamenalo, že ''httpd'' prejde do chybného stavu a služba prestane bežať, čo spôsobí výpadok služby pre klientov. Odhalenie a odstránenie príčiny je nesmierne dôležité, ale za určitých okolností chceme, aby služba bežala naďalej, než zistíme, prečo v skutočnosti spadla. V manuálovej stránke nájdeme parameter ''Restart='', ktorý dovoľuje práve špecifikovať, za akých okolností sa má daná služba reštartovať.
+<code>
+# najprv simulujme pad httpd bez zmeny nastaveni
+(root)$ pkill -SIGSEGV httpd
+(root)$ systemctl status httpd
+● httpd.service - The Apache HTTP Server
+   Loaded: loaded (/usr/lib/systemd/system/httpd.service; disabled; vendor preset: disabled)
+  Drop-In: /etc/systemd/system/httpd.service.d
+           └─override.conf
+   Active: failed (Result: core-dump) since Mon 2019-04-22 13:29:06 CEST; 1s ago
+     Docs: man:httpd.service(8)
+  Process: 7177 ExecStart=/usr/sbin/httpd $OPTIONS -DFOREGROUND (code=dumped, signal=SEGV)
+ Main PID: 7177 (code=dumped, signal=SEGV)
+   Status: "Running, listening on: port 80"
+</code>
+Upravme teda nastavenie ''httpd'' tak, aby sa pri chybe reštartoval
+<code>
+(root)$ systemctl edit httpd
+[Service]
+Restart=on-abnormal
+# overme, ze override.conf sa vytvoril nasou zmenou
+(root)$ systemctl cat httpd
+...
+ # /etc/systemd/system/httpd.service.d/override.conf
+[Service]
+Restart=on-abnormal
+...
+# teraz nastartujme httpd znovu a vyskusajme nasimulovat pad
+(root)$ systemctl restart httpd
+(root)$ pkill -SIGSEGV httpd
+● httpd.service - The Apache HTTP Server
+   Loaded: loaded (/usr/lib/systemd/system/httpd.service; disabled; vendor preset: disabled)
+  Drop-In: /etc/systemd/system/httpd.service.d
+           └─override.conf
+   Active: active (running) since Mon 2019-04-22 13:41:56 CEST; 1s ago
+     Docs: man:httpd.service(8)
+ Main PID: 7846 (httpd)
+</code>
+===Manuálové stránky===
+  * ''systemd.unit'' (5)
+  * ''systemd.service'' (5)
+  * ''systemctl'' (1)
+====Vytvárame systémovú službu====
+V predchádzajúcej sekcii sme si na príklade ukázali ako zmeniť konfiguráciu existujúcej služby. V tejto sekcii si vytvoríme vlastnú službu úplne od začiatku. V našom prípade pôjde o systémovú službu a preto budú potrebné práva **roota** po celý čas.
+Vyrobme službu, ktorá nám zaloguje aktuálny dátum a nazvime ju **mydate.service** a vytvoríme príslušný súbor v ''/etc/systemd/system'' s nasledujúcim obsahom:
+<code>
+(root)$ cat /etc/systemd/system/mydate.service
+[Unit]
+Description=Ukazem datum
+[Service]
+Type=oneshot
+ExecStart=date
+</code>
+Parameter ''Type='' hovorí, o aký druh služby sa jedná, naša služba je jednorázová (angl.//oneshot//), teda vypíše dátum a skončí. Parameter ''ExecStart'' zase vraví, čo sa má vykonať, ak spustíme službu, v našom prípade sa zavolá ''date''. \\
+K tomu, aby systemd vedel o našej novej službe je potrebné najskôr zabezpečiť, že súbor má správne SELinux práva, aby ho systemd mohol vôbec čítať.
+<code>
+(root)$ ls -lZ /etc/systemd/system/mydate.service
+-rw-r--r--. 1 root root unconfined_u:object_r:systemd_unit_file_t:s0 0 Apr 22 13:54 /etc/systemd/system/mydate.service
+(root)$ restorecon -FRvv /etc/systemd
+Relabeled /etc/systemd/system/mydate.service from unconfined_u:object_r:systemd_unit_file_t:s0 to system_u:object_r:systemd_unit_file_t:s0
+</code>
+Teraz už môžeme povedať systemd o našej novej službe, to sa robí príkazom ''daemon-reload''.
+<code>
+(root)$ systemctl daemon-reload
+(root)$ systemctl list-unit-files -t service mydate.service
+UNIT FILE      STATE
+mydate.service disabled
+</code>
+Po naštartovaní služby by sme mali vidieť zmenu v logu:
+<code>
+(root)$ systemctl start mydate
+(root)$ systemctl status mydate
+● mydate.service - Ukazem datum
+   Loaded: loaded (/etc/systemd/system/mydate.service; disabled; vendor preset: disabled)
+  Drop-In: /etc/systemd/system/mydate.service.d
+           └─override.conf
+   Active: inactive (dead)
+(root)$ journalctl -e -u mydate
+Apr 22 14:01:27 skoleni systemd[1]: Starting Ukazem datum...
+Apr 22 14:01:27 skoleni date[8755]: Mon Apr 22 14:01:27 CEST 2019
+Apr 22 14:01:27 skoleni systemd[1]: Started Ukazem datum.
+</code>
+Zároveň vidíme, že tým, že je naša služba nastavená ako //oneshot//, tak ihneď prejde do stavu **inactive**. Ak by sme chceli zachovať stav **active** aj keď proces už skončil, môžeme tak učiniť parametrom ''RemainAfterExit''.
+<code>
+(root)$ systemctl cat mydate.service
+# /etc/systemd/system/mydate.service
+[Unit]
+Description=Ukazem datum
+[Service]
+Type=oneshot
+ExecStart=date
+# /etc/systemd/system/mydate.service.d/override.conf
+[Service]
+RemainAfterExit=yes
+</code>
+Ďalej by sme chceli, aby sa naša služba púšťala vždy po štarte systému, tak ju skúsme povoliť, ako sme si ukazovali vyššie
+<code>
+(root)$ systemctl enable myservice
+The unit files have no installation config (WantedBy, RequiredBy, Also, Alias
+settings in the [Install] section, and DefaultInstance for template units).
+This means they are not meant to be enabled using systemctl.
+Possible reasons for having this kind of units are:
+) A unit may be statically enabled by being symlinked from another unit's
+   .wants/ or .requires/ directory.
+) A unit's purpose may be to act as a helper for some other unit which has
+   a requirement dependency on it.
+) A unit may be started when needed via activation (socket, path, timer,
+   D-Bus, udev, scripted systemctl call, ...).
+) In case of template units, the unit is meant to be enabled with some
+   instance name specified.
+</code>
+Systemd nám hneď povie, že s našou konfiguráciou nie je niečo vporiadku. Chýba nám tam totiž sekcia ''[Install]'', ktorá je pre systemd kľúčová, pretože mu vraví, kedy našu službu môže spustiť (služby totiž môžu mať na sebe závislosti). Tu sa dostávame k téme **//targets//**.
+====Systemd target====
+Systemd **target** je špeciálny druh jednotky, ktorý zoskupuje iné jednotky a vytvára tak určitý synchronizačný //checkpoint// pre služby, ktoré majú definované závislosti, napr. nemá význam spúšťat webserver, keď nemáme spustený **NetworkManager** a nemáme nakonfigurovanú sieť. Takáto závislosť sa potom prejaví v konfigurácii ''httpd'' nasledovne
+<code>
+$ systemctl cat httpd
+[Unit]
+...
+After=network.target remote-fs.target nss-lookup.target httpd-init.service
+...
+</code>
+Takýchto synchronizačných bodov je v systemd niekoľko a tie úplne najzákladnejšie korešpondujú s operačnými režimami sytému **SysV**, známymi ako //**runlevels**//. Hoci systemd rozoznáva aj //runlevels//, správame sa k nim jednotne ako aj k iným //targets//. Mapovanie medzi starými //runlevels// a systemd je pekne vidno [[https://wiki.archlinux.org/index.php/systemd#Mapping_between_SysV_runlevels_and_systemd_targets|tu]].\\
+Vráťme sa teda k našej službe a nastavme ju ako službu spustiteľnú vrámci ''multi-user.target'' a službu povoľme:
+<code>
+(root)$ systemctl cat mydate
+...
+# /etc/systemd/system/mydate.service.d/override.conf
+[Service]
+RemainAfterExit=yes
+[Install]
+WantedBy=multi-user.target
+(root)$ systemctl enable mydate
+Created symlink /etc/systemd/system/multi-user.target.wants/mydate.service → /etc/systemd/system/mydate.service.
+(root)$ systemctl status mydate
+● mydate.service - Ukazem datum
+   Loaded: loaded (/etc/systemd/system/mydate.service; enabled; vendor preset: disabled)
+...
+</code>
+===Manuálové stránky===
+  * ''systemctl'' (1)
+  * ''systemd.target'' (5)