6.2 Diagnostika a optimalizácia servera

V ideálnom svete by server IoT stačilo len nainštalovať podľa návodu a už nič viac neriešiť. Realita je však iná a je treba pripraviť sa na rôzne komplikácie.

Diagnostické nástroje

Niekedy sa stane, že niečo nám nefunguje. V takejto situácii je dobré poznať aspoň niektoré základné nástroje pre získanie informácií a diagnostiku. Začnime so získavaním informácií o operačnom systéme a počítači:

hostnamectl # komplexné informácie o OS, kerneli, základnej doske, BIOS verzii
uname -a # základné informácie o OS

Prehľad o využití systémových prostriedkov:

df -h # voľné miesto na diskoch
free -h # využitie operačnej pamäte
btop # prehľadný monitoring CPU, pamäte, disku, siete a procesov

Prehľad hardvéru:

lscpu # detailné informácie o CPU
lsusb # zoznam USB zariadení
lsblk # zoznam diskov

Prehľad sieťových rozhraní a adries:

# {rozhranie} je napr. enp1s0
ip -brief address # stručný zoznam sieťových rozhraní a IP adries
ip -br a # to isté, ale skrátene
ip -brief link # stručný zoznam sieťových rozhraní a MAC adries
ip -br l # to isté, ale skrátene
ethtool {rozhranie} # podporované rýchlosti a funkcie + aktuálny stav a rýchlosť
lshw -C network # model a pripojenie sieťových rozhraní, rýchlosti nemožno veriť

Použité nástroje by mali byť súčasťou každej inštalácie Linuxu, s výnimkou btop, ktorý sme si nainštalovali v predošlej kapitole.

Všetky nasledujúce príkazy v tejto kapitole vykonávame s root právami. Pred začatím práce zadajte príkaz sudo -i.

Testovanie stability

Pokiaľ to so serverom myslíme vážne, základnou požiadavkou je jeho spoľahlivosť a stabilita. Tá môže byť ohrozená aj chybami hardvéru, najčastejšie chybnými pamäťovými modulmi, či nedostatočným chladením pri plnej záťaži. Preto je vhodné pred nasadením servera a pri každej zmene pamätí vykonať diagnostiku. Záťažové testy simulujú extrémne podmienky, ktoré môžu odhaliť skryté chyby napájania alebo chladenia ešte predtým, než serveru zveríte dôležité údaje.

Môžeme na to využiť testy stress-ng a memtester, dostupné cez APT:

apt install stress-ng memtester

Ukážka konkrétnych testov:

# test CPU a cache (cca 10 minút):
stress-ng --class cpu-cache --cache-enable-all --seq 0 --verify --tz --verbose --timeout 10

# maximálne zahriatie CPU, sekvenčne a paralelne (cca 10 minút):
stress-ng --cpu 0 --cpu-method fft --vecwide 0 --vnni 0 --str 0 --wcs 0 --cpu 0 --verify --tz --seq 0 --timeout 100
stress-ng --cpu 0 --cpu-method fft --vecwide 0 --vnni 0 --str 0 --wcs 0 --verify --tz --timeout 600

# testy pamäte (cca 10 minút):
stress-ng --class memory --seq 1 --verify --verbose --timeout 10
stress-ng --vm 1 --vm-bytes 75% --verify --timeout 600

# cyklický dôkladný test pamäte:
memtester {veľkosť}G # treba zadať maximálne 90 % *voľnej* operačnej pamäte

Stav disku

Samostatným problémom je stav disku. Niekedy disk slúži len ako miesto pre uloženie súborov operačného systému, aby mohol naštartovať, no často je to aj miesto ukladania údajov, o ktoré by sme len neradi prišli bez varovania.

S.M.A.R.T.

Väčšina diskov podporuje monitoring stavu S.M.A.R.T. (Self-Monitoring, Analysis, and Reporting Technology), z ktorého vieme zistiť zaujímavé údaje, ako napríklad počet hodín prevádzky, počet štartov, počet chybných blokov, teplotu a podobne. Pre zistenie týchto zaujímavých údajov slúži program smartctl, ktorý je treba najskôr nainštalovať:

apt install smartmontools

A následne už môžeme získavať informácie - v uvedených príkazoch je treba {disk} uviesť konkrétne, napríklad /dev/sda alebo /dev/nvme0n1 - zoznam diskov získame príkazom lsblk:

smartctl -i {disk} # detailné informácie o modeli disku
smartctl -H {disk} # celkový stav (PASSED / FAILED)
smartctl -A {disk} # detailné informácie o stave disku

Stavové parametre S.M.A.R.T.

Posledný uvedený príkaz vypíše mnoho informácií, z hľadiska bezpečnosti uložených údajov nás na SATA diskoch (HDD i SSD) zaujímajú predovšetkým tieto parametre, ktoré by v ideálnom prípade mali byť na hodnote 0:

• 5 - Reallocated_Sector_Ct (počet premapovaných sektorov): Týka sa mechanického HDD (fyzické poškodenie platne), ale aj SSD (opotrebované bunky flash pamäte). Keď disk nájde fyzicky poškodené miesto, označí ho za zlé a nahradí ho „náhradným“ sektorom zo špeciálnej rezervnej oblasti. Ak toto číslo rastie, disk sa rozpadá. Ak je číslo stabilné, disk sa dá ešte používať, ale už mu netreba veriť.

• 197 - Current_Pending_Sector (čakajúce sektory): Sektory, ktoré disk nevedel prečítať a „čakajú na verdikt“. Akonáhle na ne disk úspešne zapíše dáta, zistí, či sú v poriadku  alebo ich musí premapovať (presunúť do ID 5). Týka sa to mechanického HDD - pri SSD sa nečaká, rieši sa okamžite.

• 198 - Offline_Uncorrectable (neopraviteľné sektory): Sektory, ktoré disk nedokázal opraviť ani pomocou vlastných mechanizmov pri vnútornom teste. Sú nenávratne stratené.

• 199 - UDMA_CRC_Error_Count (chyby prenosu): Toto nehovorí o zdraví platní, ale o probléme s káblom alebo konektorom. Ak toto číslo nie je 0, pravdepodobne je zlý SATA kábel alebo zlý kontakt.

Ďalšie informácie sú skôr štatistické, ale môžu nás zaujímať:

• 9 - Power_On_Hours (počet hodín prevádzky): Pre mechanický HDD je to „tachometer“ - staré disky sú náchylnejšie na mechanickú únavu ložísk a motora. Pre SSD má nižšiu výpovednú hodnotu, no i elektronické súčiastky „starnú“.
• 12 - Power_Cycle_Count (počet zapnutí): Koľkokrát bol disk zapnutý/vypnutý. Pre mechanický disk je najväčší stres práve štart (roztočenie platní). Disk, ktorý beží 5 rokov v kuse, je na tom často lepšie ako ten, ktorý bol 5 rokov zapínaný 10-krát denne. V prípade SSD nie je tento údaj až tak podstatný, no príliš vysoké číslo môže poukazovať na problémy s napájaním.

• 194 - Temperature (teplota): Teplota mechanického HDD by nemala dlhodobo presahovať 45 - 50 °C. Každých 10 stupňov navyše drasticky skracuje životnosť ložísk a magnetickej vrstvy. V prípade SSD je kritická hranica cca 70 °C, pri prehrievaní disk začne spomaľovať.

Testovanie S.M.A.R.T.

Na SATA diskoch (nie NVMe) môžeme spustiť aj S.M.A.R.T. testovanie - počas neho je možné disk používať, no bude spomalený a neodporúča sa to. Lepšie je testovať mimo prevádzky (napríklad v noci):

smartctl -t short {disk} # spustenie rýchleho testu (cca 2 až 5 minút)
smartctl -t long {disk} # spustenie dlhého testu (cca 1 noc)
smartctl -l selftest {disk} # protokol posledných testov

NVMe disky

V prípade NVMe diskov je situácia mierne odlišná - autodiagnostiku si robia priebežne počas prevádzky a neumožňujú spúšťať test manuálne. Zistené údaje nemajú číselné ID a sú trochu inak pomenované:

• Critical Warning: U NVMe diskov je toto najdôležitejšie pole. Na rozdiel od SATA diskov, kde musíme sledovať desiatky atribútov, NVMe zjednodušuje diagnostiku do tohto kritického indikátora. Ak je tam 0x00, všetko je OK. Akékoľvek iné číslo znamená prehrievanie alebo vážnu hardvérovú chybu.
• Available Spare: Je to ekvivalent k 5 - Reallocated_Sector_Ct, ale obrátene - určuje, koľko je ešte k dispozícii záložnej kapacity, teda 100 % je ideálny stav nového disku. SSD má vždy niečo „navyše“, čo nie je viditeľné pre používateľa. Keď nejaká pamäťová bunka umrie, disk ju nahradí bunkou z tejto zálohy.
• Media and Data Integrity Errors: Ak je tu niečo iné ako nula, disk má problém s pamäťovými čipmi a začína prichádzať o dáta.
• Percentage Used: SSD majú obmedzený počet zápisov. Toto číslo ide od 0 % (nový) do 100 % (opotrebovaný). Keď dosiahne 100 %, neznamená to, že hneď umrie, ale už prekročil záruku výrobcu na počet zápisov.
• Data Units Written: Udáva, koľko dát (logických jednotiek, zväčša 1000 sektorov po 512 B) disk už zapísal. Výrobcovia garantujú napríklad 600 TB pre 1 TB disk.
• Údaje Power On Hours, Power Cycles a Temperature majú rovnaký význam, ako pri SATA SSD (uvedené vyššie).

Súborový systém

V dnešnej dobe sú SSD disky už samozrejmosťou, ktorá výrazne zvyšuje rýchlosť spúšťania operačného systému i aplikácií, ale aj rýchlosť inštalácie. Či sa jedná o staršie SATA SSD disky, prechodné M.2 SATA disky alebo modernejšie NVMe disky, v každom prípade sa jedná o flash pamäť, ktorá má teoreticky obmedzený počet prepisov jednotlivých pamäťových buniek. Hoci pre moderné NVMe to z praktického hľadiska bežne nie je problém a skôr disk vyhodíme pre jeho nepostačujúcu kapacitu ako by sme ho „zodrali“, pri serveroch sa situácia môže značne líšiť.

Niektoré servery potrebujú disk len na to, aby mali z čoho spustiť operačný systém a zapisujú naň len veľmi zriedka - tam disk vydrží „takmer večne“. No sú servery, a to v prostredí IoT veľmi časté, ktoré na disk sústavne ukladajú nové údaje do databázy a nové udalosti do protokolov. Preto by sme mali disk čo najviac šetriť a pri inštalácii OS je vhodné zvážiť výber súborového systému. Súborový systém môžeme v nainštalovanom OS zistiť rôznymi spôsobmi, napríklad:

lsblk -f

Btrfs

Pri inštalácii Linuxu je obvykle predvolený systém ext4, ktorý je síce rokmi overený a stabilný, ale bol navrhnutý ešte v ére magnetických pevných diskov. Pre moderné servery s flash pamäťami je lepšou voľbou Btrfs (B-tree filesystem) alebo F2FS. V inštalátore klasického Linuxu (pre PC) je možné určiť rozloženie diskových oddielov a ich súborový systém), a tak nám nič nebráni zvoliť systém Btrfs:

Súborový systém Btrfs má viaceré výhody, no pre nás sú podstatné hlavne tri:

• Pri prepise súboru novou verziou systém neprepisuje tie isté pamäťové bunky, ale zapíše novú verziu na iné voľné miesto - táto metóda sa nazýva Copy-on-Write (CoW). To zvyšuje bezpečnosť údajov (pri výpadku napájania neprídeme o pôvodný súbor) a umožňuje efektívne vytváranie snímok súborov (spomínané ďalej v texte). Zároveň to prispieva k rovnomernejšiemu opotrebovávaniu pamäťových buniek.
• Umožňuje zapnúť transparentnú kompresiu údajov, čo samozrejme aj ušetrí miesto (a to v prípade protokolov a iných textových súborov veľmi zásadne), ale môže dokonca aj zvýšiť rýchlosť čítania i zápisu (hlavne pri rýchlom CPU a pomalšom SSD), pretože nie je potrebné ukladať také množstvo údajov.
• Snímky (snapshots) umožňujú urobiť „fotku“ stavu celého disku pred nejakou väčšou zmenou a ak sa niečo pokazí, môžeme sa veľmi jednoducho vrátiť k predošlému stavu.

Pozor na databázy: Hoci je CoW skvelá vlastnosť pre stabilitu systému, pre súbory s častým náhodným zápisom (ako sú databázy) spôsobuje extrémnu fragmentáciu. Súbor sa rozkúskuje na tisíce častí, čo spomaľuje procesor a reakcie servera. V takých prípadoch je lepšie je lepšie CoW pre konkrétny priečinok s databázu vypnúť, čo sa neskôr pri inštalácii konkrétnych služieb aj naučíme. O ochranu pamäťových buniek pred opotrebovaním sa pri moderných SSD diskoch postará ich vlastný riadiaci čip. V tomto prípade nie je potrebná ani ochrana pri náhlom výpadku, pretože moderné databázy používajú žurnál - najskôr si zapíšu zámer vykonať zmenu údajov a až následne ju vykoná, takže pri nečakanom výpadku sa vie zotaviť. Ochranu údajov teda preberá samotný databázový systém a súborový systém sa „stiahne do úzadia“, aby nebrzdil výkon.

Kompresia súborov

Samotné zvolenie súborového systému Btrfs však nezaistí kompresiu údajov. Tú je treba vyžiadať pridaním parametra „compress=zstd“ k pripájanému disku, a to úpravou súboru /etc/fstab:

nano /etc/fstab

Sú tam v samostatných riadkov všetky pripájané diskové oddiely v tvare:

• {diskový oddiel} {bod pripojenia} {súborový systém} {parametre} {dve nepodstatné čísla}

Nás zaujímajú parametre - tie môžu byť viaceré (obvykle je ako prvý defaults), oddeľujú sa čiarkou (pozor, bez medzery!) a práve tam dopíšeme požadovaný parameter pre zapnutie kompresie. Situácia po zmene môže vyzerať napríklad takto:

/dev/disk/by-uuid/d1d29cff-26e6-402e-8802-b791b451e275 / btrfs defaults,compress=zstd 0 1

Experti môžu ku kompresii zstd pridať za dvojbodku ešte stupeň kompresie (po 15, teda „zstd:15“) - predvolená je hodnota 3, čo je rozumný kompromis medzi efektivitou kompresie a záťažou CPU. V prípade veľmi rýchleho CPU by možno mohlo mať zmysel zvýšiť stupeň kompresie, no reálne to už neprinesie až taký rozdiel vo veľkosti údajov. A naopak, pre príliš starý a slabý CPU je možné zvoliť rýchlejší kompresný algoritmus lzo - ten samozrejme komprimuje menej. Ďalšie detaily nájdete v dokumentácii Btrfs - časť o kompresii.

Po pridaní parametra kompresie je treba ešte vykonať reštart a po novom nabehnutí OS sa ukladané údaje už budú komprimovať. A čo všetky tie staré, tie doteraz uložené? Tie zostanú, ako boli, no je možné ich skomprimovať aj dodatočne - čo môže trvať veľmi dlho, pokiaľ je na disku veľa údajov:

btrfs filesystem defragment -czstd -r /

S tým, že symbol „/“ na konci je priečinok, ktorého súbory sa majú komprimovať, v tomto prípade ide o koreňový priečinok, teda komprimovať sa budú všetky pripojené disky a ich oddiely, ktoré sú v systéme Btrfs. Parameter -czstd hovorí, že sa má komprimovať algoritmom zstd.

Transparentná kompresia je skvelá vec, no určite nás bude zaujímať aj výsledok - koľko miesta na disku sme ušetrili. To je možné zistiť nástrojom compsize:

# nainštalujeme nástroj compsize
apt install compsize
# ak ho nenájde, môžeme skúsiť
apt install btrfs-compsize
# prípadne nájsť jeho presný názov cez
apt search compsize

# a teraz konečne zistíme štatistiku celého súborového systému (root priečinok /)
compsize -x /

Zdržanie pri štarte servera

Súborový systém Btrfs prináša vcelku kuriózny problém: každý štart sa zdrží o 30 sekúnd. Nie je to vinou Btrfs, ale boot manažéra GRUB. Ten dokáže z Btrfs čítať údaje potrebné na štart, ale nedokáže naň zapisovať. Preto tomu nevie po úspešnom štarte zmazať príznak zlyhania, a tak pri každom ďalšom zapnutí „pre istotu“ čaká na zásah používateľa.

Toto zdržanie môžeme odstrániť pridaním inštrukcie GRUB_RECORDFAIL_TIMEOUT=0 do konfiguračného súboru /etc/default/grub a následnou aktualizáciou zavádzača:

echo "GRUB_RECORDFAIL_TIMEOUT=0" >> /etc/default/grub
update-grub

Viaceré sieťové rozhrania

Niekedy má server viaceré sieťové karty (napríklad integrovanú 1 Gb/s a prídavnú 2,5 Gb/s). Pokiaľ nie sú do siete pripojené obe, Linux môže pri štarte uviaznuť až na 2 minúty v stave networkd-wait-online, pretože sa snaží nakonfigurovať všetky dostupné rozhrania.

Riešenie je však jednoduché - v konfigurácii Netplanu (súbor /etc/netplan/*.yaml) označíme rozhrania ako voliteľné parametrom optional: true. Systém tak naštartuje okamžite a sieťovú adresu si na danej karte vypýta až vtedy, keď do nej reálne zapojíme kábel. Vyzerať to môže napríklad takto:

network:
  version: 2
  ethernets:
    enp1s0:
      dhcp4: true
      dhcp6: true
      optional: true
    enp2s0:
      dhcp4: true
      dhcp6: true
      optional: true

Pri zmenách sieťových nastavení je treba byť veľmi opatrný - obzvlášť v prípade konfigurácie „na diaľku“, čo je v praxi takmer vždy. Asi nik nechce po chybe zostať odpojený! A chyba sa spraví veľmi ľahko, v YAML stačí zle odsadiť… Preto je vhodné zmenené nastavenia otestovať príkazom netplan try - ten aplikuje nastavenia ihneď, no pokiaľ zmeny do 2 minút nepotvrdíme, vráti ich späť. Nepripomína nám to Safe Mode na zariadeniach MikroTik, ktorý nás neraz zachránil pri práci v kurze počítačových sietí? 😉

Môžeme všetky sieťové rozhrania označiť ako voliteľné?
V podstate áno. Je však situácia, kedy by to mohol byť problém: Ak by sme mali na serveri pripojené sieťové disky (NFS, Samba) cez /etc/fstab. Pokiaľ pri štarte nie je dostupná sieť, pokus o namontovanie týchto diskov pri štarte zlyhá. Otázne je, či by prípadné čakanie pomohlo - to už musí každý zvážiť v konkrétnej situácii.

Aktualizácia firmvéru

Kým softvér aktualizujeme cez APT, na aktualizáciu hardvéru (jeho firmvéru) slúži nástroj fwupd, ktorý je treba najskôr nainštalovať:

apt install fwupd

Tento nástroj je v praxi použiteľný najmä pre mini PC s architektúrou x86 od výrobcov ako Dell (modely Optiplex), Lenovo (ThinkCentre), HP (EliteDesk, ProDesk, Z-Workstation), či Intel (NUC). Ostatní výrobcovia túto formu, žiaľ, veľmi nepodporujú.

Poznámka: Na Raspberry Pi sa pre tento účel používa špecifický nástroj rpi-eeprom-update.

Tento nástroj dokáže priamo z terminálu aktualizovať firmvér, no vyžaduje, aby bol systém nainštalovaný v režime UEFI. Výrobcovia týmto spôsobom môžu posielať dôležité bezpečnostné záplaty nielen pre hlavný BIOS / UEFI základnej dosky, ale aj opravy pre SSD disky, sieťové karty, či TPM moduly. Pri IoT serveri, ktorý beží non-stop, chceme mať záplaty proti kritickým chybám, akými boli napríklad Spectre a Meltdown.

Použitie nástroja fwupd:

fwupdmgr refresh     # stiahnutie informácií o nových verziách
fwupdmgr get-devices # zobrazenie informácií o zariadeniach
fwupdmgr get-updates # kontrola dostupných aktualizácií
fwupdmgr update      # vykonanie aktualizácie

Pre vykonanie aktualizácie je po skončení procesu takmer vždy potrebný reštart systému. Či je to skutočne tak, zistíme prítomnosťou súboru /var/run/reboot-required.

Aktualizácia mikrokódu CPU

Okrem firmvéru existuje ešte jedna špecifická vrstva „opráv“ hardvéru -  mikrokód procesora. Sú to drobné opravy chýb v logike procesora od výrobcov Intel alebo AMD. Hoci sa tieto opravy môžu dostať do počítača cez aktualizáciu BIOSu, výrobcovia základných dosiek ich často vydávajú so značným oneskorením.

Operačný systém Linux však dokáže tieto opravy aplikovať sám pri každom štarte (bootovaní). Je to najrýchlejšia cesta, ako zabezpečiť procesor proti známym zraniteľnostiam, aj keď výrobca PC už nevydáva nové verzie BIOSu. Slúžia na to nástroje intel-microcode a amd64-microcode, ktoré sú v Linuxe bežne predinštalované a každá aktualizácia systému nainštaluje aj prípadné opravy mikrokódu.

Či je systém a procesor aktuálne v bezpečí a či má aplikované všetky dôležité záplaty, je možné kedykoľvek overiť nahliadnutím do systémových súborov:

tail /sys/devices/system/cpu/vulnerabilities/*

Tento príkaz vypíše zoznam známych hrozieb a pri každej z nich uvedie stav (napríklad Not affected alebo Mitigation). Ak je pri niektorej položke uvedené Vulnerable, znamená to, že počítaču chýba aktualizácia BIOSu alebo mikrokódu.

Prípadne si môžeme zobraziť len zraniteľnosti, možné varianty príkazu:

grep -r "Vulnerable" /sys/devices/system/cpu/vulnerabilities/
lscpu | grep "Vulnerable"

Žiaľ, nie vždy je dostupná oprava (hlavne pre staršie CPU), no v domácom prostredí IoT servera v LAN to zvyčajne nepredstavuje kritické bezpečnostné riziko.

Zvuková signalizácia

Určite to nie je potrebné, ale môže byť zaujímavé náš server obohatiť o zvukové signály, pokiaľ na základnej doske máme bzučiak (buzzer, speaker). Ubuntu ho má štandardne úplne vypnutý, no server nie je desktop a nám môže poslúžiť.

ugly and loud noise, getting on everyone's nerves; this should be done by a nice pulseaudio bing
(komentár k zariadeniu pcspkr v Ubuntu Server)

Aby sme mohli vôbec bzučiak používať, v súbore /etc/modprobe.d/blacklist.conf je potrebné zakomentovať riadok so zákazom zariadenia pcspkr:

sed -i "s/blacklist pcspkr/#blacklist pcspkr/" /etc/modprobe.d/blacklist.conf

# a aby začal fungovať hneď, nie až po reštarte:
modprobe pcspkr

Pípnutie pri štarte

Boot manažér GRUB umožňuje pípnuť pri svojom spustení, teda v okamihu, keď BIOS odovzdá riadenie operačnému systému. V súbore /etc/default/grub je potrebné povoliť konzolový formát parametrom GRUB_TERMINAL=console a pridať samotný zvuk parametrom GRUB_INIT_TUNE="údaje", kde údaje sú postupnosť: tempo frekvencia_1 trvanie_1 frekvencia_2 trvanie_2 … Trvanie nemá konkrétnu jednotku, ale súvisí s tempom: (60 / tempo) je trvanie hodnoty 1. Pre jednoduchosť je vhodná hodnota 600, vtedy 1 trvanie znamená 0,1 s.

Príklad aktivácie dvojitého pípnutia (získanie mince v hre Super Mario):

sed -i "s/#GRUB_TERMINAL=console/GRUB_TERMINAL=console/" /etc/default/grub
sed -i 's/#GRUB_INIT_TUNE=.*/GRUB_INIT_TUNE="600 988 1 1318 4"/' /etc/default/grub 
update-grub

Melódie pri udalosti

Aby sme mohli pohodlne generovať tóny kedykoľvek (zväčša v skriptoch pri nejakej udalosti), oplatí sa nainštalovať si beep a nášmu používateľskému účtu prideliť právo používať bzučiak:

apt install beep

# ak má byť beep funkčný aj pre používateľa, nielen pre systém:
usermod -aG input $(logname)
#prejaví sa až po odhlásení a opätovnom prihlásení používateľa

Celkom praktické by bolo zahratie zvučky, keď štartovanie OS skončí a systém je pripravený - teda po nabehnutí všetkých služieb. Dá sa to dosiahnuť jednoducho vytvorením vlastnej služby. Najskôr v priečinku /etc/systemd/system vytvoríme službu, napríklad s názvom boot-beep:

nano /etc/systemd/system/boot-beep.service

Do tohoto súboru vložíme jej popis:

[Unit]
Description=pípnutie po úspešnom štarte
After=multi-user.target

[Service]
Type=oneshot
ExecStart=/usr/bin/beep -f 440 -l 50 -n -f 554 -l 50 -n -f 659 -l 50 -n -f 880 -l 150
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target

A následne službu zaktivujeme:

systemctl enable boot-beep.service