Hová tűntek a logok? Systemd?

Linux-kezdő

Tudna valaki segíteni abban, hogy hová tűntek a logok. Évtizedeken keresztül volt egy log mappa, amiben szinte minden log elérhető volt, és hiba esetén egészen hatékonyan lehetett használni. Debian 12 óta azonban erősen megcsappant ennek a mappának a tartalma, és sem syslog, sem kern.log, sem egyebek nincsenek benne. Ellenben örökké ajánlgatja a

journalctl

parancsot mindenféle paraméterezéssel, hogy valami logszerű infóhoz jussak.

Biztos van ennek valami értelme. Nem systemd utáló topicot szeretnék, hanem hogy megértsem, mi ez az új rendszer, és miért jobb, mint az eddigi.

  • 1835 megtekintés

( peterson v | 2023. 10. 25., sze – 14:01 )

Szerkesztve: 2023. 10. 25., sze – 14:02

Biztos van ennek valami értelme.

Van, csak sokunknak nem tetszik.

Nem systemd utáló topicot szeretnék

Ezzel a témaindítással nehéz lesz elkerülni. :) 
Lásd kivel van dolgod, nem fejtem ki a pro és kontra érveket, hogy ne én indítsam be a "I (love|hate) systemd" vonatot. :D

"A megoldásra kell koncentrálni nem a problémára."

( gigalomania v | 2023. 10. 25., sze – 14:02 )

Szerkesztve: 2023. 10. 25., sze – 14:05

Under systemd, both kernel and system messages are logged by the journal service systemd-journald.service (a.k.a journald) either into a persistent binary data below "/var/log/journal" or into a volatile binary data below "/run/log/journal/". These binary log data are accessed by the journalctl(1) command. For example, you can display log from the last boot as:

$ journalctl -b

Table 3.5. List of typical journalctl command snippets

Operation Command snippets
View log for system services and kernel from the last boot "journalctl -b --system"
View log for services of the current user from the last boot "journalctl -b --user"
View job log of "$unit" from the last boot "journalctl -b -u $unit"
View job log of "$unit" ("tail -f" style) from the last boot "journalctl -b -u $unit -f"

Under systemd, the system logging utility rsyslogd(8) may be uninstalled. If it is installed, it changes its behavior to read the volatile binary log data (instead of pre-systemd default "/dev/log") and to create traditional permanent ASCII system log data. This can be customized by "/etc/default/rsyslog" and "/etc/rsyslog.conf" for both the log file and on-screen display. See rsyslogd(8) and rsyslog.conf(5). See also Section 9.3.2, “Log analyzer”.

 

https://www.debian.org/doc/manuals/debian-reference/ch03.en.html

( XMI | 2023. 10. 25., sze – 14:15 )

Van olyan disztro (pl RHEL es szarmazekai) ahol ugy van konfiguralva, hogy legyen tovabbra is /var/log/messages es a journald is tovabbitja oda a logokat. Szoval ez kb "ahany haz annyi szokas" esete.

Elvileg az lenne az ertelme a journald-nek, hogy nem egy plaintext logod van, kb kotetlen formatummal, ami akar fileon belul is valtozhat, mondjuk a boot folyamat kulonbozo szakaszaiban. Helyette van nehany standard mezo, ilyenek mint severity, unit, timestamp stb. ami szerint lehet leszurni keresgelni benne. Mindezt anelkul, hogy mindenfele grep, awk, cut, sed magic-eket kelljen csinalni.

Ami mondjuk hatranya, hogy valojaban nincs indexelve a mezok szerint, igy a kereses... finoman szolva... lassabb, mint egy szovegfileban. Regebben baja volt, hogy hajlamos volt korruptalodni a journal file, ha pl nem tisztan allt le a rendszer. Ezeket a bajokat ma mar nagyjabol kijavitottak.

Régóta vágyok én, az androidok mezonkincsére már!

Nem is tudom, elég bonyolult az a sylog-ng a modern igényekhez?

filter f_warn_emerg { level(warn .. emerg); };
destination d_warn_emerg { file("/var/log/warning.log"); };
log { source(s_src); filter(f_warn_emerg); destination(d_warn_emerg); };

filter f_info_emerg { level(info .. emerg); };
destination d_info_emerg { file("/var/log/info.log"); };
log { source(s_src); filter(f_info_emerg); destination(d_info_emerg); };

Persze így is sokkal jobb, mint a hagyományos:

*.warning /var/log/warning.log rotate size 1m time 1m files 4 compress
*.info    /var/log/info.log    rotate size 1m time 1m files 4 compress

De ha csak ennyi, akkor lehet, hogy telepítem az rsyslog csomagot, és én is maradok a régi módszernél

csak ne feledd, hogy ezzel (várhatóan) duplikálod a logokat ,amivel elég könnyen be lehet tölteni a local diszket...

Az sem mindegy, hogy 1 szerverről van szó, vagy több 100 vagy akár 1000 szerver logjairól beszélünk. :)

 

egy single otthoni 'játszós' szerver esetében, valóban csak felteszed és a default konfig visszaadja a 'régi' feelinget ;)

(nagy tételben azonban ez kifejezetten káros következményekkel járna)

zrubi.hu

Nalam mindenhol Storage=volatile van, igy "ramba" pakolja a binaris logokat (igy a journalctl-el/systemctl status-al latom logokat visszafele), a hosszutavu tarolasert meg a hagyomanyos syslog-ng+logrotate felel. kaposzta+kecske esete :)

A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

( Raynes v | 2023. 10. 25., sze – 18:50 )

Nincs mit megérteni, hülyeség az egész systemd. A logolási része főleg. Használható persze, ha megtanulod használni, de logikát meg hatékonyságot azt ne keressél benne, mert nem fogsz találni. Nem is értem miért volt jó a spanyolviaszt feltalálniuk, miért nem volt jó a hagyományos plain text logfile, rendes rotációban, a /var/log/-ba, ahová való. Tipikusan corporate nagy céges idiótáknak támad ilyen kerék-újrafeltaláló ötlete, ha unatkoznak az irodában két meeting között.

Egyébként ha mégis valamiféle logikát akarsz benne keresni, akkor az van mögötte, hogy az Apple initrendszerét másolta Poettering. Az Apple-nek meg az lehetett a logikája, hogy saját formátumú, bináris logokba az esetleges kártevők nem tudnak csak olyan könnyedén belehányni. Persze csak tipp, ha annyira érdekel, írj neki egy e-mailt, de gyaníthatóan nem fog válaszolni, sok utálkozó és fenyegető, kritizáló e-mailt kap a mai napig.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Journalból törölj már egyszerűen bejegyzést valahonnan célzottan a "közepéből", vagy épp szűrd ki, hogy mi menjen bele, és mi ne, stb... A syslog implementációk csak azt írják ki egy egyébként mókolható sima szöveges fájlba, amit megkapnak. Amit nem, azt nem...

"sok utálkozó és fenyegető, kritizáló e-mailt kap a mai napig" - No igen, ha valami más, mint a megszokott, ha valamit meg kellene tanulni, az sokaknak büdös... De így volt ez a sysvinit-tel is, azt se nagyon tudták rendesen használni az érintett linuxos csomagok karbantartói...Tisztelet a kivételnek...

Persze, nem is állítottam, hogy a bináris log 1) a megoldás, 2) ha megoldás is, akkor a leghatékonyabb. Simán lehet jogosultsággal is kivédeni, nyilván.

Nem az a baja a systemd-nek, hogy más, hanem hogy volt rá működő, (unixos és unix-like rendszerek között is) szabványos megoldás, ami évtizedekig be volt járatva, bizonyított, erre jött egy hülye, és egy másik hülyétől ihletve újra feltalálta a kereket, úgy, hogy kb. semmi előnye, csak más. Felesleges volt +1 dolgot azért lenyomni az emberek torkán, mert csak más, meg az előzőt meguntuk.

Egyébként pontatlanul írtam, Apple helyett azt akartam írni, hogy a MacOS init rendszerét másolta a systemd. Konkrétan a launchd-t. Majdnem minden ötletet, újítást abból szedett, csak nem nevezhette ugyanúgy a dolgokat, mert az Apple beperelte volna, így a nevek, helyszínek meg lettek változtatva.

A systemd-nek egyébként nem is az a baja, hogy olyan, amilyen, hanem hogy erőszakkal lett lenyomva mindenki torkán, és nem is a Red Hat, vagy Pöcstering jóvoltában, hanem a sok felelőtlen fejlesztő dependelte rá a szutykait, ami miatt ott kell lennie a legtöbb rendszeren. Ha csak egy szabadon lecserélhető initrendszer lenne, akkor nem lenne vele gond, akinek ez tetszik használná, akinek nem tetszik lecserélné bármikor, és senkinek nem lenne gondja vele.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Tehát a hagyományos szöveges sysloggal írt fájlok szerinted jók, megbízhatók, stb... Igaz, rendszergazda joggal simán tudod mókolni a tartalmukat, simán meg tudod oldani, hogy bizonyos események ne kerüljenek bele - satöbbi. Az, hogy a fejlesztők felfogták, hogy nekik miért jó, az a dolgok egyik fele - az meg a másik, hogy a vaskalapos SVR4 vagy picit újabb szinten megragadt rencergizdák meg nem... így jártak - fel kell fogni, hogy az OS az nem a rendszergazda pélóméregetésére való, hanem arra, hogy azon alkalmazások fussanak, olyanok, amik kihasználják a rendszer lehetőségeit. Ha kell, akkor a init-rendszer függőségkezelését, ha kell, akkor a naplózást...

Lecserélheted. Forkolhatsz egy systemd-mentes rendszert, és évek alatt eljuthatsz oda, hogy minden lényeges csomagból - megfelelő motiváció megléte esetén - lesz systemd-től független verzió, az upstream-et rendben követve/karbantartva. Csak erőforrás kérdése...

Részben egyetértek veled.

Mindazonáltal a logok nem várt módosítása / törlése ellen nem a bináris log a megoldás. Hanem a logszerverek, abból is több és redundánsan elhelyezve. A logszervereket meg nem ugyanazok az adminok kezelik, mint a normál szervereket.
Persze mókolni ekkor is lehet - pl: elmegy a hálózati kapcsolat a logszerverek felé.

A logszerverbe az megy át, amit a helyi logger megkap, _és_ nem akad meg a hálózat torkán... Innentől kezdve például egy alkalmazás saját logja, amit _nem_ tud direktben logba küldeni, hanem a loggernek kell felolvasni, az remote-ba átküldve "bármi is" lehet, bármit is tartalmazhat. függetlenül attól, hogy a forrás oldalon mi került a fájlba. Lehet persze láncolt hash-t implementálni a naplózásba, meg hasonló trükköket csinálni, hogy a módosítás, logsor kihagyása legalább észlelhető legyen...

És a bináris log hogy véd meg attól, hogy saját programmal csinálj egy új bináris fájlt?

Max. a vi-tól véd.

Ha nagyon fontos, hogy ki tudd mutatni, hogy belenyúltak, akkor valamilyen kriptográfiai módszert kell használni (hash-t generálni, digitálisan aláírni, stb.)

Persze, jobban, mert pl. ha vi van a gépen, ahol el akarod tüntetni a nyomaid, és gcc, python, perl, stb. meg nincs, akkor nem tudsz bináris fájlt hamisítani, ellenben a text logban nyomhatsz dd-t az adott sorra.

Kb. mint az 123456 jelszó is jobban véd, mintha nem lenne jelszó.

az kemeny ha ezt valahol megtehetik anelkul hogy az audit figyelne ra, masreszt komoly helyen a log megy mindenhonnan (system, apps, trace) a kozponti logstore-ba hogy ott analizaljak es azonnal roasszanak vagy az ML anomaliakat keressen :D

Ez jo nagy faszsag a a binaris log vedelmere :D

Ha nyomnal egy dd-t valahol adott sorra (nem tudnal, de ha megis tudnal) kb egy percen belul ertesulne rola az illetekes csapat es masnapra mehetnel rapportra hogy "ugye csak veletlen volt", de a sor amugy is meglenne a kozpontban

Csak szolok hogy a 80-as eveknek vege, meg ha szep kamaszkorom is volt akkor :D

mert csak nagyvallalati kornyezetben tudsz gondolkodni! egy pistike bt, ahol van egyszem vps/server a sajat custom appjukra, ott nincs kozponti log meg ML meg kiskutyafule. ok alljanak ott letolt gatyaval? semmilyen cucc onmagaban nem silverbullet, de hasznos/kompromisszumos epitoeleme lehet egy-egy rendszernek.

A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

Tehat azt mondod, hogy a bt alkalmaz egy informatikust mert az majd nem dd-zik bele a binaris logokba? vagy nem ertem :D

A "Marika bt"-nel ki a faszomat fog erdekelni, hogy az informatikus mit csinal barmilyen loggal is legyen az binaris vagy clear text? Raadasul a journalctl hibaja miatt megallhat a gep, de egy elbaszott text file miatt nem. 

Vagy ugy gondolod, hogy a "Marika bt" security osztaja majd mindig vizsgalja a logok, akar binaris akar text helyesseget?

Osszezavarsz. Mi az allitas:

1. A systemd binaris logok kurvajok, mert a Marika bt.-bennem tudja senki sem felulirni oket?????

2. Az app cutsom logjait celszeru a journalctl-be irni syslog, jaeger meg barmi helyett, mert a Marika bt munkatarsai onnan konyebben es hatekonyabban ertik meg a custom app performanc issue-it?

Vagy nincs semmi allitas csak hogy "a systemd es a jornalctl jo mer csak" :D

"a journalctl hibaja miatt megallhat a gep" - NEM hiba, hanem tervezett működés: HA a naplózás nem működik, a napló sérült, akkor az egy kivizsgálandó esemény/incidens. Ha egy tevékenységet _nem_ tudok a naplóba beírni, akkor azt _nem_ szabad végrehajtani.

A mancikabácsibéténél ezt le lehet tojni, de van, ahol ez az elvárt viselkedés - mancikabácsibété informatikuspistikéje meg oldja meg, hogy a journal ne sérüljön meg.

Ja, a syslog tud gpg-vel aláírt logot produkálni?

Azt hiszem, itt két szemlélet ütközik. Az egyikben a napló integritásának van prioritása, a másikban a gép működőképességének. Valószínűleg mindkettőnek megvan a helye. Magam részéről nem tartom jó ötletnek, hogy alapértelmezetten a napló integritása magasabb prioritású, mint a működőképesség, de lehet, hogy a számok tükrében ez egy reális döntés volt. Az azonban fura, hogy ez egy kizárólagos döntés, és nem választható.

és nem választható.

Erről tudunk többet? Nálam Linux Mint-en többször volt már rendszerindításnál, hogy jött az üzenet, hogy megromlott a zsurnál, úgyhogy megy a polcra, és helyette készül egy új, de ezzel együtt is mindig elindult a rendszer. Ez beállítástól függ, vagy esetleg a systemd változattól? (Nálam most `systemd 249 (249.11-0ubuntu3.11)` van.)

Ettem, ha tehat a systemd/journalctl elbassza a logokat (egen, egen bezony elofordult nem is egyszer) akkor inkabb ne induljon el a szolgaltatas es menen a levesbe az SLA, mert majd az ugyfel elgedetten felsohajt, hogy de legalabb a logok integritasa tok serult. Mert ez egy feature hogy a systemd elbassza a logokat es ez igy tokeletes. Inkabb legyen elbaszott systemd log, mint szolgaltatas. Remek. Nem baj ha ilyen cegnel nem akarok dolgozni ugye?

Amit irsz, hogy gpg-vel alairni a logokat meg mar megint nem a Marika BT-nel lesz requirement. Innentol meg enterptrise-rol beszelunk. Onnantol meg a joisten mentsen meg attol, hogy a systemd/journald hulyesegre kelljen biznom barmit is :D

Amugy meg SELinux es Audit segit azon, hogy tudjuk mikor ki irhat milyen logot es hogy mikor is tortent violation. Ugy hogy nem kell elegedetten sohajtanunk hogy de legalabb nem tudunk szolgaltatni :D

Meg mindig nem tudom a kerdest amire a valasz a journalctl lenne :D

Amugy erdekelne hogy hogyan vizsgalod ki a serult megnyithatatlan es hasznalhatatlan journalctl naplotbol hogy mi a fasz tortent mikozben onhold-ba teszed addig a szolgaltatast (jo ideig varhat akkor az ugyfel) :D

Amikor még dolgoztam vele, akkor a syslog-ng fizetős változata még tudott aláírt és hitelesített naplót.

Általánosságban nincs bajom a journald-vel, de nem is szeretem. A leginkább idegesítő hogy amikor `journaltcl -u something -e -f`-el "várok" a gépen hogy eljusson a boot folyamat az általam kívánt pontra gyakran előfordul hogy semmit nem látok. Egy Ctrl-C és felnyíl, Enter megoldja, de attól még zavaró.

Az meg hogy a journal sérülése miatt meg is álljon a szolgáltatás vagy sem szerintem helyzet függő. Van ahol ez szükséges, vagy javasolt és van ahol az a fontosabb hogy menjen tovább. Egy banknál az előbbi lehet a preferált, egy lélegeztető gépen meg az utóbbi.

Viszont ha bele dd-zel a bináris logba, akkor következő rebootnál megáll majd a systemd a boot közben és mehetsz single user módba kipuceválni, hogy egyáltalán összeszedje magát a rendszer. Mert egy log inkonzisztens...

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

Nem. Pont ez a bukta benne, hogy hiába is teszel fel másik initrendszert, másik naplózási megoldást, stb., a systemd részelemeinek továbbra is futni kell, udevd, (e)logind, stb.. Működik, de becsapod magad, hogy nem használsz systemd-t, közben meg de, mert egyes részei továbbra is ott fognak futni a rendszeren. Mondom, ez nem is magán a systemd-s fejlesztőkön múlik, hanem más csomagok fejlesztőin, hogy mire dependelik rá a fejlesztéseiket.

Ezért adta be a legtöbb disztró a derekát, meg én is. Mert ha már úgyis egyes részeinek ott kell lennie a rendszeren, akkor már nyugodtan végezze el az initrendszer feladatát is, felesleges széllel szemben hugyozni.

Egyébként a BSD-knek pont ez az előnye. Konzervatívak, maradtak a jól bevált, POSIX szabványos megoldásnál, nem akartak feltalálni semmilyen kereket, se GNU kiterjesztések, se systemd, se Snap, Flatpak, se egyéb világmegváltás. Cserében rosszabb hardvertámogatás (kevesebb driver ugyebár), rosszabb szoftveres támogatás (pl. nuku Docker, Proton, natív Steam, Netflix-támogatás, stb.), gyérebb fájlrendszer-választék, alacsonyabb fokú optimalizálás sebességre (jóval lassabban futnak ezek a rendszerek azonos gépen a Linuxhoz képest), stb. jellemző ezekre, mint a Linuxra. Így az előnyök-hátrányok kiegyensúlyozódnak. Mindenki eldöntheti, hogy mi a fontos neki.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Értő olvasás: tessék forkolni egy olyan disztrót, amiben csak systemd-től független csomagok vannak. Amik meg vital component-ként kellenek, abból meg tessék csinálni saját, systemd-mentes forkot. Jaaaa, hogy ez q.sok meló, meg jó esélye van annak, hogy nem lesz rá ember, aki csinálja? (upstream systemd-s függésű forrás javításait, fejlesztéseit folyamatosan backportolni a sajátba - úgy, hogy azt esélyesen senki sem finanszírozza...)

A snap meg a flatpack az nekem is bögyömben van - oké, hogy ezzel elintézhető a disztribúció-független "csomagok" készítése, de anno a statikusan fordított binárisokat is csak kifejezetten arra tartotta az ember, ha annyira szétesik a rendszer (nem is unix-os rendszergazda, aki nem törölt véletlenül libc-t...), hogy csak a statikus bináris tud futni és rendet rakni, ezek a csodák meg hozzák magukkal a jóég-tudja-milyen-verziójú komponenseket, amik a rendszerben vagy újabbak, vagy nem, vag bennük lukasabb, vagy nem... Hogy a működési anomáliákról (böngésző csak snap-ben...) ne is beszéljünk... Lustulnak a fejlesztők, fogynak a csomagkarbantartók - öregszik a szakma :-D

Igen, sok meló, de létezik ilyen disztró. Csak általában elég lassan frissülnek az ilyeneknél a csomagok, meg korlátozott a csomagválaszték, mivel a csomagfenntartóknak meg kell oldani, hogy kiszedik a vonatkozó csomagokból a systemd-re dependelő részeket, és megoldják, hogy fusson, és ezt minden új verziónál el kell játszani. Enyhén szólva is gigantikus meló. Amit nem is a systemd okoz, mint írtam, hanem a sok idióta soydev, akik mindenáron a systemd-re dependelik rá a fejlesztésüket, nekik kell megköszönni.

Én egyébként nem vagyok ellene az univerzális csomagoknak, csak akkor, ha olyan gusztustalanul nyomják rá a userre, mint az Ubuntu a Snap-ot, meg még néhány disztró (Elementary, Silverblue, stb.) a Flatpakot. Opciónak jók ezek, ha valaki máshogy nem tud felszögelni egy szoftvert, ami nincs a hivatalos bináris tárolókban, és forráskódból nem fordul le neki, vagy nem akar gyenge gépen napokat forráskódot forgatni, akkor egyfajta alternatív megoldásnak elmennek ezek. Esetleg ha egy szoftverből többféle verziót is akarsz egyszerre tartani a rendszeren. Vagy el akarod választani egy program frissítési mechanizmusát a rendszerétől, én pl. használok pár dologra Appimage-t, pl. LibreOffice, mert nem fontos, hogy ultra friss legyen, ritkán használom, és nem akarom, hogy az Arch húzogassa le hozzá a frissítéseket minden nap, vagy pl. Goldendict, aminél meg nem akarom, hogy sok függőséget telepítsen a natív csomagkezelő, és azokat frissítgesse naponta. Szóval okosan használva megvannak ezeknek az előnyei, csak nem kéne a felhasználókra gusztustalanul rátolni, ha kell, ha nem alapon, hanem a rendeltetésének megfelelően használni.  

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Breaking news: Pöcstering mester új systemd feature-ön dolgozik. Áldásos keze munkájának örök hála. Pedig állítólag nem haszontalan funkció, de szerverre való.

Ez a másik érv a systemd ellen, hogy mindig bővítik, ilyen szemszögből lehet mégis jobb lecserélni initrendszerként hosszú távon.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Ja, ez a másik ami zavar benne, ezt az új feature-t is a MacOS-ből lopta, mert mi másból. Még az se baj, hogy mekes fetisiszta, vegyen meket, használjon MacOS-t, és legyen azzal boldog, a Linuxot nem kéne mekesíteni. Főleg nem mindenkire rátolva kötelező jelleggel. Azzal nem lenne bajom, ha mondjuk csinál egy MacOS koppintásos DE-t, WM-t, vagy témát, mert azt opcióként felrakná, használná, aki akarja, de a systemd az mindenkinek kikerülhetetlen.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

( Dwokfur v | 2023. 10. 26., cs – 06:19 )

A legszebb, amikor korruptnak érzékeli a systemd a bináris logjait, akkor be sem boot-ol...

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

Ez sem rossz, de tud még szépeket:

beáll a szolgáltatás, és a port közé. Innen kezdve ha a szolgáltatás portját meg szeretnéd változtatni, kérd meg szépen a systemd-t. Utána változtathatsz configban portot. Ha a kettő azonos, akkor restartolhatod a service-t. Ja, nem... Úgy nem cseréli le. Stop és start. Akkor igen. Ez például ssh-nál kínos tud lenni.

De azért szeretjük. Kicsit. Sem. Inkább nem. Sőt... :D

"A megoldásra kell koncentrálni nem a problémára."

"Ez például ssh-nál kínos tud lenni." - csak ügyesen kell csinálni:
screen-ben indítani:  sleep 10; stop; sleep 5; start; sleep 120 ; vissza_az_egész.sh
ctrl+a, d, kilápsz, sshd újraindul, ~30s múlva megpróbálsz belépni, ha sikerül, akkor a vissza_az_egesz.sh -t szépen eltakarítod. Ha nem sikerül belépni, vagy bármi zacc adódott a stop6start kapcsán, akkor a vissza_az_egesz.sh scripted visszacsinálja a módosításokat, és újrarúgja a szolgáltatást.

Egyébként nem szeretni kell, hanem megismerni, tanulni, tanulni, tanulni - és a sz@r unit fájlokat rendberakni, és a csomagkarbantartó felé jelezni, hogy másképp kéne csinálni.

"És mit csinál a stop a session-nel? ;)"

Na mit?

root@bnc1:~# systemctl stop sshd
root@bnc1:~# w
 14:47:31 up 117 days,  8:00,  1 user,  load average: 0.00, 0.00, 0.00
USER     TTY      FROM             LOGIN@   IDLE   JCPU   PCPU WHAT
fisher   pts/1    134.xx.xx.xx   14:45    3.00s  0.01s  0.01s sshd: fisher [priv]
root@bnc1:~# ps -ef| grep [s]shd
root      384093       1  0 14:45 ?        00:00:00 sshd: fisher [priv]
fisher    384099  384093  0 14:45 ?        00:00:00 sshd: fisher@pts/1
root@bnc1:~# ssh localhost
ssh: connect to host localhost port 22: Connection refused

Ez is egy probléma a systemd-vel...

Egyébként próbáltad utána kiadni a startot? Ha sikerült az gáz. Ha nem, akkor érted mire gondoltam. ;)

[szerk:] a stopnak ugyanis le kellene állítania szolgáltatást. A példád szerint nem sikerült neki. :(

"A megoldásra kell koncentrálni nem a problémára."

A connection refused nekem azert inkabb jelenti azt hogy az megallt, mint hogy nem.

Ugye van egy ilyen:

$ systemctl cat sshd | grep -i killmode
KillMode=process

Pont azert, hogy egy stop/start ne gyakja ki az osszes balszerencses usert.

Amugy ja, starttal el is indult, most szomoru lennek ha nem.

Pont azert, hogy egy stop/start ne gyakja ki az osszes balszerencses usert

Mások az elveink. Én úgy gondolom, hogy az álmos könyv szerint rossz ómen, ha a bejelentkezett user az egyik configgal megy, az újonan bejelentkező meg egy másikkal. A magam részéről elvárnám, hogy egy szolgáltatás leállítása annak session-jeit is mérlegelés nélkül gyakja ki.

Az meg kultúra kérdése, hogy az ops figyelmezteti-e előtte a usert. Én szoktam.

"A megoldásra kell koncentrálni nem a problémára."

Hatto... most mar ehes vagyok, megyek haza, de igy ranezesre az a baj, hogy az sshd nem tudja reloadolni a konfigot:

$ man sshd| grep -ci reload
0

Egyreszt ezt nem irnam a systemd szamlajara, masreszt meg ugyanez lenne a problema sysv inittel is (meg mindennel is).

Ugye azzal, ami tudja reloadolni, azzal nincs baj, pl. apache.

Hacsak úgy nem. Éreztem én hogy át kéne olvasni, de az éhség nagy úr :D

Viszont akkor meg végképp nem értem hogy mi a baj...

fisher@j0:~$ sudo systemctl reload sshd
fisher@j0:~$ sudo ss -tulnp | grep sshd
tcp   LISTEN 0      128                              0.0.0.0:4444       0.0.0.0:*    users:(("sshd",pid=515,fd=3))                                                                                                                                         
tcp   LISTEN 0      128                            127.0.0.1:6010       0.0.0.0:*    users:(("sshd",pid=1626901,fd=9))                                                                                                                                     
tcp   LISTEN 0      128                                [::1]:6010          [::]:*    users:(("sshd",pid=1626901,fd=7))                                                                                                                                     
tcp   LISTEN 0      128                                 [::]:4444          [::]:*    users:(("sshd",pid=515,fd=4))                                                                                                                                         

fisher@j0:~$ sudo sed -i 's/4444/6666/' /etc/ssh/sshd_config ; sudo systemctl reload sshd ; sudo ss -tulnp | grep sshd
tcp   LISTEN 0      128                              0.0.0.0:6666       0.0.0.0:*    users:(("sshd",pid=515,fd=3))                                                                                                                                         
tcp   LISTEN 0      128                            127.0.0.1:6010       0.0.0.0:*    users:(("sshd",pid=1626901,fd=9))                                                                                                                                     
tcp   LISTEN 0      128                                [::1]:6010          [::]:*    users:(("sshd",pid=1626901,fd=7))

Csak ne felejtsem el 22-re visszatenni...

Ja, restarttal is:

fisher@j0:~$ sudo sed -i 's/6666/7777/' /etc/ssh/sshd_config ; sudo systemctl restart sshd ; sudo ss -tulnp | grep sshd
tcp   LISTEN 0      128                              0.0.0.0:7777       0.0.0.0:*    users:(("sshd",pid=1627130,fd=3))                                                                                                                                     
tcp   LISTEN 0      128                            127.0.0.1:6010       0.0.0.0:*    users:(("sshd",pid=1626901,fd=9))                                                                                                                                     
tcp   LISTEN 0      128                                 [::]:7777          [::]:*    users:(("sshd",pid=1627130,fd=4))                                                                                                                                     
tcp   LISTEN 0      128                                [::1]:6010          [::]:*    users:(("sshd",pid=1626901,fd=7))

Hacsak nem az a baj, hogy ilyenkor nem vág ki mindenkit... de ugye a reloadnak pont ez lenne a lényege. A restart meg... na igen, de ezt már fent megvitattuk.

"A magam részéről elvárnám, hogy egy szolgáltatás leállítása annak session-jeit is mérlegelés nélkül gyakja ki."

Az sshd egyike a nagyon keves kivetelnek, alapertemezetten kaszal "mindent" (control-group). Es tenyleg masok az elveink, en nem banom hogy az sshd nem rantja ki alolam a gepet ha megallitom. De ugye... erre van az override file, egyszeruen meg lehet valtoztatni a unit mukodeset.

igen, amikor otthon a barkacs szerveredet tutujgatod, akkor nem problema ha kivagod magad alol az ssh-t. de amikor bennvan a gepen mondjuk 20-30 esetleg 100 user, akik _dolgoznak_ is benne, akkor nemjo otlet csak ugy restartolni. persze nyilvan igenyelhetsz ra restart idoablakot, de a mostani mukodik egy sokaknak jo megoldas. akinek meg nemtetszik az modosit rajta.

A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

Csaxólok, hogy ezt az sshd csinálja: alapesetben a systemd-től egy a stop során egy SIGTERM (15) signal-t kap, amire úgy reagál, hogy a meglévő session-ök maradnak, de már nem fogad új kapcsolatokat. (Kifejezetten fail-safe megoldás egyébként)

Átírhatod úgy a unit fájlt, hogy a "stop" során az összes sshd processz menjen a levesbe, ehhez javaslom az "ExecStop" és a "KillMode" tanulmányozását.

Nem az a kérdés, hogy meg tudom-e kerülni, vagy át tudom-e gányolni a problémát.

Az a gáz, hogy a probléma megszületett. A systemd-vel.

Egyébként nem szeretni kell, hanem megismerni, tanulni

Eddig oké. Próbálom, mert nincs választásom. De szopat.

sz@r unit fájlokat rendberakni, és a csomagkarbantartó felé jelezni, hogy másképp kéne csinálni.

Talán nem kellett volna rákényszeríteni a világra ekkora kapkodással, és erőszakkal. Akkor nem mindenkinek kéne debugolni a bug-halmot, elég lett volna ha a kitalálói (megérdemelten) szenvednek vele. 

"A megoldásra kell koncentrálni nem a problémára."

Ez nem a systemd-vel jött be, hogy bizonyos alkalmazások ilyen változtatás során stop/start igénnyel élnek. Nekem például az sshd soha nem okozott gondot, sem akkor, amikor sshd-t cseréltem, sem akkor,amikor konfigot módosítottam, és újra kellett rugdosni - az élő session megmaradt - a régi binárissal/beállításokkal, az újonnan érkező kéréseket meg már az új szolgálta ki. Akkor is, ha a portot cseréltem le...

"Eddig oké. Próbálom, mert nincs választásom. De szopat."

Hát bizony, a tanulás rögös útjai... Ilyenkor kell két lépést hátralépni, "elfelejteni" az instant, adott problémára fél oldalban megoldást nyújtó oldalakat, és megpróbálni az alapoktól megérteni, felfogni, hogy hogyan is működik, mi miért lett úgy megvalósítva, ahogy.
Lehet, hogy néhány nap elmegy az alapokkal, de utána sok "szopat" jellegű dolgot helyből meg fogsz érteni, hogy miért van, és miért pont úgy...

"Talán nem kellett volna rákényszeríteni a világra ekkora kapkodással, és erőszakkal. " -sokszor leírtam, és itt is megteszem: onnantól,hogy a faék egyszerű sysvinit-et sem tudták (tisztelet a ritka kivételnek) rendesen használni (futási szintek kérdésköre, respawn és környéke, stb.), nem csodálkozom, hogy egy valóban sokkal bonyolultabb - vagy inkább összetettebb - megoldást sem sikerül...

faék egyszerű sysvinit

Kimondtad a kulcsszót. Miért volt baj az egyszerűség, és kezelhetőség?

Másik hasonló topicban írtam az egytrükkös pónikról. De az már nyilván ízlés dolga. :)

Szerintem a systemd fordítva közelített. Nem meghágni kellett volna vele a Debiant, és csinálni egy forkot (Devuan) nélküle, hanem csinálni kellett volna egy systemd-s forkot, és ha szerelmesei kitesztelték, a fejlesztői pedig javították akkor implementálni.

De ez a magánvéleményem. 

"A megoldásra kell koncentrálni nem a problémára."

De még azt sem bírták rendesen használni!!! Az egyes futási szintek (0 és 6 kivételével) nem igazán voltak megkülönböztetve, nem használták azokat értelmes (sőt semmilyen) módon... Anno a slowaris esetén még megvolt a single user / multiuser / multiuser+hálózat /multi+háló+X11...

És lám, a sysvinit-nél jóval összetettebb, rugalmasabb eszközt pláne nem tudják rendesen használni, sem pedig user/admin oldalról megérteni, hogy mi mért és hogyan működik benne. Ahogy az sem megy felfogásilag, hogy miért is jó a deklaratív megközelítés a sysvinit scripthalmazos, imperatív irányvonalával szemben.

"Talán nem kellett volna rákényszeríteni a világra ekkora kapkodással, és erőszakkal."

Szerintem pont az ellenkezoje a baj vele. 15+ eve letezik, ez mar regen nem a kapkodas kategoria. Rengeteg apro, de bosszanto (komplett feature-oket hasznalhatatlanna tevo, vagy csunya workaroundot igenylo) bug pont ugy megvan ma is benne, mint 15 evvel ezelott. Voltak bugreportok, voltak patchek bekuldve, de sok esetben nem volt upstream fejlesztoi nyitottsag a javitasra.

Régóta vágyok én, az androidok mezonkincsére már!

Nézd, már nem tudom, mit csináltam pontosan azon a júniusi napon, de azóta nincs fájlba mentett zsurnálom, pedig `Storage=persistent`, a lemezen bőven van hely, a zsurnálverifáj szerint minden PASS, és rendszerindítás után zöld a systemd-journald. Ha viszont utóbbit újraindítom, az nem sikerül neki, és onnantól "journal stopped", és csak annyit mond, hogy FAILED, de hogy miért, azt nem. (És akkor én vagyok a hülye, hogy egy Odüsszeiányi doksi elolvasása nélkül nem sikerül kitalálnom, mi baja őkelmének.) Nem értem, miért panaszkodnak rá annyian: egyszerű, átlátható, teszi a dolgát. Jó ez. :)

( peterson v | 2023. 10. 26., cs – 12:20 )

Natessék. Én szóltam 1. hsz-ben... 😆

És ez még csak az eleje...

"A megoldásra kell koncentrálni nem a problémára."

( derWRK | 2023. 11. 08., sze – 11:07 )

Hát ez mégiscsak átment flame-be :)

Különben nem is lenne gond a systemd-vel, ha normálisan működne így tizenpár év után, és legalább normálisan lehetne paraméterezni.

Mert pl. lehet vitatkozni azon, hogy jó-e a ramba logolni, vagy elinduljon-e a rendszer egy sérült naplóval, de ezeknek normálisan konfigolhatónak kéne lenni igény szerint.... akár a képébe is kéne tolja az egyszeri usernek rögtön egy disztró telepítő kérdésként.

Persze egyébként is egy bloatware, szóval viszlát KISS (keep it simple, stupid.. tehát ne írjunk olyan programot ami mindent is csinál), és a bináris rendszerlog meg a threat everything as a file ellenében dolgozik ).

Valamelyik korábbi nagyobb lánngal flamező topicban írta valaki, hogy utálja a systemd hatereket, nekem meg az ugrott be, hogy akkor én meg a systemd hater hatereket utálom és így tovább és így tovább...

Az (r)syslog(ng) problémája meg nem (csak) az hogy bármit bele lehet írni, hanem pl. hogy első dolga volt annó a nem root betőrőnek annyi naplót küldeni bele, hogy teljen meg a fájlrendszer ( igen, a fenntartott hely is, hiszen rootként futott annó is a naplózás), és utána ha nincs távoli log már lehetett keresni, hogy mi is történt (még nem is próbáltam ki mit kezd ezzel a systemd, csak összerottyan a bináris log, vagy már előbb eldobja az üzeneteket? egyik se jó mindenkinek). A naplózásnak nem is bebetonozottként rootként kéne futnia, és nem is egy boot folyamatot megakasztó mission critical dolognak kéne lennie feltétlenül, hanem választhatónak kéne lennie...

A systemd meg akkor lenne jó, ha mondjuk a ma reggel eszembejutott egy új feature helyett, mondjuk sikerülne a kódsorok számát megfelezni és nem csak kullogni a bugfixek után (ehhez mondjuk a bloatware részt kéne elengedni),

és innentől kevesebb lenne ( lett volna ) a vita is, ha mene mondjuk egy snapd openrc-vel, vagy runittel, és mondjuk ezek mellett aki akarja használhatná a journalctl-t ha neki úgytetszik, szóval az all in one helyett tényleg szét lennének szedve a funkcionalitások, ha lehet standard api-kon keresztül.

Ja és persze a fő érv a systemd mellett, hogy hát mindenki azt használ, semmi értelme szembe menni vele. Hát jah, ezen a vonalon sose kezdtem volna linuxozni, hiszen mindenki windowst használ...

Ize, logroatet-rol azert ne feledkezzunk meg, meg arrol, hogy a log particio kulon van nem a root-on, igy tok mindegy mennyit akar-a-hova-irni a loggeren keresztul a tamado meg ha a logger daemon root-kent is fut. A barmit beleiras is kicsit fura nekem, mert meg van mondva hogy a syslog daemon milyen facility, severity eseten mit is csinaljon, szoval azert annyira akarmit nem lehet beleirni, ha valaki szepen mindent beallit.

Amugy a systemd/journalctl eseten is meg van mondva mekkora lehet a log maximum aztan megy a rotalas. Szoval ez pont nem gond vele. Ennel sokkal fundamentalisabb problemai vannak :D

A systemd meg akkor lenne jo ha nem lenne. :D (hanem valami normalis dolog lenne helyette, ami tenyleg csak a service managementet vegezne es nem ulne ra mindenre is...systemd-home-dir edesjofaszom)

Amugy az utolso mondat miatt jar a +1 :D

Én is utálom, de nekem a működésével nagy bajom nem volt. Ha nagyon bele kéne kötni a működésbe, akkor az az lenne, hogy kéne egy gyorsbillentyű, hogy a running stop/start job-ot ki lehessen lőni. Állítólag most is ki lehet, valami Ctrl+Alt+Del vagy Ctrl+Alt+Esc háromszor nyomva, de nekem nem működik. Át lehet írni a /etc/systemd/system.conf fájlban a DefaultTimeoutStartSec=90s és DefaultTimeoutStopSec=90s értékét, de akkor meg túl gyorsan lövi ki, és nem lehet elolvasni. Ezt megoldhatnák rendesen.

Egyébként igen, a kódsorok számát megfelezhetnék, de akár meg is negyedelhetnék.. Az a baj, hogy a systemd nem csak egy initrendszer. Egy ilyen általános másodlagos kernelféleség, interface a user és a valódi kernel között, lereagál eseményeket, kezel felhasználókat, hálózatot, energiakezelést, megoldja az ütemezést, naplózást, időbeállítást. Így az initen kívül ellátja a cron, syslog, userkezelés, hardverkezelés, stb. feladatait is. Ez elég durván szembe megy a Unix-filozófiával. Egy initrendszernek csak az initről kéne gondoskodnia, és az egésznek modulárisnak kéne lennie, hogy bármelyik része szabadon cserélhető legyen, külön syslog-megoldás, külön cron-implementáció, stb.. Ezt le lehet cserélni systemd-nél is, de mivel egyes szoftveres dependelnek egyes systemd modulokra, ezért nem lehet szabadulni tőlük.

Az eredeti Unixokban pont ezért használtak sysvinitet. Mert épített a rendszerrel érkező alapprogramokra, shell script, fájlok linkelése, kimenet átirányítása pipe-pal logfájlba, stb., így sok kódsort nem igényelt, általános beépített eszközökkel megoldotta, és csak az initet, meg esetleg a logolást, és kész. Nem akart egy komplett OS lenni az OS-en belül, ahogy a systemd. Nagyon nem kéne a MacOS-t meg az Apple-t másolni, sok hülyeséget csinálnak, és ezzel nincs is baj, aki ezeket akarja, használ Mac-et, aki ezt nem akarja, az ne kapja az arcába.

Ez a baj a nagy cégekkel és céges fejlesztőkkel, MS, Apple, Red Hat, Pöcstering, eldöntik a user helyett, hogy neki mi lesz a jó, mire van szüksége. Ezt én szeretném magamnak eldönteni. Ha azt akarnám, hogy más döntse el, használnék Windowst vagy MacOS-t. Nem viccből linuxozok már 9 és fél éve. Ez tetszik egyébként a Gentoo-ban. Ott szabadon eldöntheti a user, hogy milyen bootlási megoldást használ, akár az összes bootloadert kihagyhatja, és lehet a kernel a saját maga bootloadere (EFI stub boot), olyan initrendszert használ, amit akar, a binárisokba olyan függőséget fordít bele USE flag-ekkel, amit akar. Így teljesen ura a telepített rendszernek, nincs eldöntve helyette, hogy már pedig ő Grub-ot, systemd-t, Pipewire-t, Wayland-et, stb. fog használni, mert a nagy corporate overlordoknek épp az volt a víziója.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”