systemd, mi más...

Mivel már pár napja terjed twitteren, de itt még nem láttam róla semmit, bepasztázom:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=825394

Illetve Herr Pöttering ugyanerről:

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject…

( locsemege v | 2016. 05. 28., szo – 13:04 )

Szerintem rossz címet adtál ennek. Fejlődésre képtelen, pattintott kőkorszakban élő debianosok, mi más... lett volna a helyes cím. Van megoldás fordítási időben is, futásidőben konfigurálva is, ha jól látom.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Az autóban eddig a pedálokat nyomni kellett, de az új systemdés autóban papucsként bele kell dugni a lábadat (cipő nélkül, kényelmes, puha a belseje, és extraként talpmasszázst, pedikűrt és egyéb dolgokat is nyújt az új technológia), és a gyorsításhoz a középsőt kell felfelé emelni, a lassításhoz a bal szélsőt oldalra mozgatni, míg a tengelykapcsoló funkcionalitását a jobb szélső vette át, amivel kis köröket kell leírni jobbra a szét- balra az összekapcsoláshoz.
Mindezt át lehet konfigurálni OBD csatlakozón keresztül az 23MC_PEDAL_RECONF_BAD_ORIG=1 parancs elküldésével, mely minden különböző lábhoz elvégzendő.

Mindezt át lehet konfigurálni OBD csatlakozón keresztül az 23MC_PEDAL_RECONF_BAD_ORIG=1 parancs elküldésével, mely minden különböző lábhoz elvégzendő.

Meg persze a műszerfalon van rá egy kapcsoló is (gondolom a tied a fordítási idejű akart lenni, az enyém a logind.conf), de egyébként pedálonként is használható egy paranccsal, megadva, hogy melyik pedálra akarod visszaállítani...

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

( uid_19334 | 2016. 05. 28., szo – 13:07 )

"In my view it was actually quite strange of UNIX that it by default let arbitrary user code stay around unrestricted after logout."

Sokan csodálkoznak, hogy a Ms mi kárt tehet a Linuxban, mikor az bazár meg openszósz meg szabad licensz.
Tkp nem kell nagy fantázia: elég kinyitni a szemünk.

Nem igazán értem, mire gondolsz. Arra, hogy a session-ből kilépve, az adott felhasználóval tovább futó process biztonsági rés, vagy arra, hogy valami most változik - ami egyébként kikerülhető, ha valaki nagyon akarja -, és ez jaj, micsoda csapás a GNU/Linux rendszerekre, vagy valami egészen másról van szó?

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Amúgy kill helyet mit kellene csinálnom systemd alatt? A minap beragadt egy (OGlt használó) alkalmazás, az istennek nem állt le. Gondoltam kill PID xyz mint ahogy ezer éve teszem ha kell. Kiléptem grafikus felületről is közben, hátha ott akadt össze valami. Nem. Végül reboottal oldottam meg, de nem örültem neki.

☆☼♫♪♫♪☼☆
AGA@
Fork portal és az egyik logóm :)

Annak, hogy a DE alól te mit indítottál, mi köze a systemd-hez (azt leszámítva, hogy egy általa kezelt slice-hoz rendelt cgroup-ban fut)? Nem lehet, hogy az alkalmazás simán elkapja a 15-öt és nem foglalkozik vele? SIGTERM?

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

( NevemTeve | 2016. 05. 30., h – 07:10 )

Lassan itt lenne az ideje, hogy végre kimondják: emberek, az nem Unix, ez systemd-OS.
A Unix kialakult valamilyenre (főleg sokfélére) az elmúlt ötven évben, a systemd-OS meg most alakul, örüljünk, hogy részesei lehetünk a történelemnek. Akár akarjuk, akár nem. Slackware van még valahol, btw?

(off)
-- Feri bácsi, miért állította le az erőmű hűtését egy perccel azután, hogy elindította?!
-- Én nem állítottam le semmit, fiacskám, csak kiléptem a GUI-ból.
(/off)

"Hétfői történet: Szent Kristóf gyermekorvosi rendelő, Win 8.1 OS, asszisztens bekapcsolja a gépet, jön fel a GWX ablak, már X-eli is ki, indítja az orvosi szoftvert. Sorszámokkal szórakozás, stb., ~10 perc múlva azt látja, hogy a Win10 telepítése elkezdődött..."

http://itcafe.hu/tema/re_az_ablak_bezarasa_beletorodes_a_windows_frissi…

Nálam. :)
Mostanában jön majd ki a 14.2, viszont cserébe a slackware-current megszűnik ARM-on. :(
-------------------------------------------------------------------------------
Az életben csak egy dolog a szép, de az épp nem jut eszembe.

Slackware Linux 14.1 | 3.10.96-janos

( turul16 v | 2016. 05. 30., h – 10:07 )

Az User serviceket is legyilkolja ?
https://wiki.archlinux.org/index.php/Systemd/User

Vagy ez is olyasmi ami ekkor is tuleli a login sessions-t ?

szerk.: Ekkor is minden usernek egyesevel engedni kell a tulelelest (ujrainditast is tulelelo) .:
$ loginctl enable-linger <user>

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

( Chain-Q v | 2016. 05. 30., h – 12:12 )

A legjobb, hogy egy eszkombajn systemd fejleszto berepoltalta a tmuxba a bugot, hogy javitsak ki a tmuxot, mert most mas lett a systemd-ben a default... A tmux karbantartok meg nagyjabol azt kozoltek, hogy "lofaszt, mama".

Szerintem a systemd a Linux vilag Windows 10-e. Az emberek 95%-nak nem kell, nincs ra szuksege, es semmi elonyt nem nyujt a korabbiakhoz kepest, hogy van, de lenyomjak a torkukon. Az "it's a security problem" meg az ultimate erv barmi mellett es ellen is.

-=- Mire a programozó: "Na és szerintetek ki csinálta a káoszt?" -=-

+végtelen
Nem lenne semmi gond ezekkel a srácokkal, ha nem akarnák a rendszerüket összekeverni a unix-szal.

Nyilván én vagyok a hülye, de olyasmi a systemd/unix reláció, mint a C++/C reláció: annyival "jobb" az új termék, hogy már semmiben sem hasonlít a régihez, nem is kompatibilis már, legfeljebb kifogásnak használják: ez-vagy-az a feature a régi rendszerből maradt ránk, amihez egyébként semmi közünk, épp csak meglovagoltunk annak a népszerűségét.

A titteren volt egy találó tweet. Kb.: Most már a systemd/Linux korában élünk. Már átvette a GNU helyét.
-------------------------------------------------------------------------------
Az életben csak egy dolog a szép, de az épp nem jut eszembe.

Slackware Linux 14.1 | 3.10.96-janos

En azt is latom, ez honnet jon. A RedHatnel (tudtommal) van egy olyan policy, hogy minden fejlesztesuket upstreambe kell tolni, maskent a project ejtve. Ezt anno arra talaltak ki, hogy a cegnel dolgozo fejlesztok ne uljenek olyan dolgokon, amibol az egesz Linux kozosseg profitalhatna, ne 'vesszenek el' ezek a dolgok, miutan a megrendelo megkapta. Ennek a policynek rengeteget koszonhet az egesz Linuxos kozosseg.

A policy arnyoldalait viszont pont a systemd, es hasonlo projektek mutatjak meg. A RedHatnal barkinek brainfartja van, ha tovabb akar dolgozni a projektjen, akkor valahogy upstreamet kell belole csinalni es el kell fogadtatni a RedHaten kivuli "kozosseggel". Ezert volt anno olyan aggressziv marketingje a systemd-nek, ezert nyomtak mindenhova esznelkul - amellett, hogy persze a rajta dolgozok egojat is taplalni kellett valamivel.

A fentiek kombinacioja (egy jo policy rossz alkalmazasa, egy nem-problemakra valaszul keszult nem-megoldas fejlesztese, ami polipkent terjeszkedik szet a rendszerben, az aggressziv marketing, es ego driven development) miatt ruhellem annyira a systemd-t.

-=- Mire a programozó: "Na és szerintetek ki csinálta a káoszt?" -=-

Azt mondod, hogy a Fedorába/RedHat-ba bement, mert házi és upstream, meg a többi.

ezert nyomtak mindenhova esznelkul

Ezzel azt mondod, hogy szerinted a Gentoo (afaik nem default) és Slackware (afaik egyáltalán nem is csomagolják) karbantartóin/fejlesztőin kívül MINDENKI gondolkodás nélkül vette át, felült egy hype trainre és meg sem állt systemdiáig?

Ha pedig igen: annó a Fedora 9 / RHEL 6 idejében hogy nem ültek fel a disztrók ugyanerre a hype trainre és váltottak Upstart-ra, követve a piros kalaposokat? Nem lehet, hogy mégis meggyőző a feature setje és azért terjedt el?

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Az hogy a distro maintainerek ráugrottak, semmit se jelent. Én tökre megértem, ha az ő munkájukat megkönnyíti, ergó egy rakás dolgot "készen" kapnak, amit eddig per distro meg kellett csinálni. Jót tesz a Linuxok között átjárhatóságnak is (cserébe kapsz egy monolitikus toolra épülő monokultúrát, amiről külön el lehetne vitatkozni, mindegy). De ez nem teszi invaliddá azt, amit fentebb írtam.

-=- Mire a programozó: "Na és szerintetek ki csinálta a káoszt?" -=-

(cserébe kapsz egy monolitikus toolra épülő monokultúrát, amiről külön el lehetne vitatkozni, mindegy)

Merthogy? Kötelez bárki arra, hogy (mint szoftverfejlesztő vagy üzemeltető) befejezd a shell scriptek init.d-be pakolását? Használatod pont ugyanannyira semmire, mint anno a SysV idejében.

A monolitikus tool másik oldala meg az, hogy attól függ :) Mit tekintesz tool-nak? Az egész systemd ernyőprojektet (hostnamed, timedated, localed, logind, machined, importd, resolved, ... - csak azokat írtam, amiről a systemd oldalon van linkelve On X cikk), vagy magát a systemd init rendszert? Mert a fentiek ugyan a Freedesktop-os systemd repókban vannak, systemd-* a nevük, de valójában sima DBus aktivált szolgáltatások. És egyiket sem kötelező használnod, kivéve, ha használsz olyan alkalmazásokat, amik dependelnek az általuk nyújtott interfészekre (és van, amelyikre van alternatív implementáció).
Fejlesztőként viszont egy sokkal robosztusabb platformot kapsz, ha systemd-t használsz/feltételezed, hogy követik a standardjaikat. Továbbra is bedobhatod az init.d-be a shell scriptedet, viszont pl. tudod használni a /etc/os-release fájlt és nem a disztró * verzió különböző esetet kell egyesével kezelned. Ha meg konkrétan kihasználod a systemd szolgáltatásait, akkor kézhez kapsz kulcsrakészen olyan (biztonsági, konfigurációs, kényelmi stb.) olyan funkciókat, amiket egyébként N+1. alkalommal meg kéne írnod (vagy egy másik library-re dependendelned...)

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

ráérő idő hiányában egy részt kiragadva:

>de valójában sima DBus aktivált szolgáltatások

nálam már ezen elbuknának, nem kell még ráadásul poetteringwarenak lenniük

A DBus controller ugyanis nem service manager, az aktiválást meg csak systemcancerral képes megoldani, vagy annak híján saját maga, annak minden hátrányával. Amikor jó pár évvel ezelőtt az upstart egyik fejlesztője megpróbálta megpatchelni a DBust, hogy ugyan vegyen már tudomást az upstart által menedzselt serviceekről, akkor valami, arrogáns "épp most akarom átvariálni az egész szart hogy még inkompatibilisebb legyen" "érvvel" söpörte le.

Ez egyben válasz arra a felvetésedre is, hogy egyiket sem kötelező használnod. Persze, nem kötelező, de ha már egyik-másik systemd komponens betette a lábát a rendszerbe, akkor lehetetlen lesz az ilyen kis buziskodások miatt elkerülni a többit. Úgy terjed mint a rák.

Jah, hogy a systemd feature-jei (DBus aktivált service) kellene, de a systemd rohaggyon meg? Ugyanis továbbra is megteheted, hogy szépen elindítasz init scriptből egy alkalmazást, ami beregisztrálja magát a DBus-on (mert az egy specifikáció, több implementációval) és üldögél idle-ben, ugyanazokat a hívásokat exportálva, mint a systemd-* szolgáltatások. A systemd csak azt oldja meg, hogy ne kelljen a fél világnak idle-ben futnia a háttérben.

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

>Jah, hogy a systemd feature-jei (DBus aktivált service) kellene

jelenlegi állapotában nem, épp erre próbáltam kilyukadni

és Poetterix a garancia arra, hogy ez így is marad, azaz nem lesz egy általános aktivációs mechanizmus, ami nem csak a systemd-vel teszi megoldhatóvá, hogy az elindított szolgáltatások kezelve legyenek

Összefoglalva, hogy miért is utálják annyian Poetteringet és terrorista bandáját:

1) újít valamit (DBus aktiváció) ami magában hordoz egy problémát (kezelés nélkül indulnak daemon processek [életciklus kezelés, logolás, stb]
2) "megoldja" a saját maga által kreált problémát (--systemd-activation)
3) nem hagyja hogy más is megoldja --> kénytelenek lesznek használni a szarját, ha nem akarnak lemondani az általa kínált előnyről (esetünkben: a DBus-on keresztül történő aktiválás)

Fenti séma egyébként felismerhető szinte az összes FreeDesktop.org-os/poetteringes "innovációnál"

1) újít valamit (DBus aktiváció)

Tehát a rohadék megcsinálta azt, amit 20 éve az inetd a socket aktivációval, ezért utáljuk. De az inetd jó, mert régi (vagy valami ilyesmi).

2) "megoldja" a saját maga által kreált problémát

Tehát ami egy mondattal fentebb újítás volt, az most már (annak ellenére, hogy külön pontként szerepel, pedig ugyanazt írtad le kétszer) a saját maga által kreált probléma megoldása. Hint: a DBus-t NEM Poettering csinálta (a specifikáció 6 szerzőjéből csak 2 Red Hat-os).

3) nem hagyja hogy más is megoldja

Van más D-Bus implementáció? Van (sőt, a freedesktop-os referencia-implementációt portolják pl. Windows-ra, ahova AFAIK még nem ért el Poettering mocskos keze és nem systemd van alatta...). A socket aktiválás működése fekete dobozként működik? Dehogy. Az sd-bus API-ját stable-nek nyilvánították? Igen. Egész pontosan HOGYAN akadályoznak meg akárkit, hogy implementáljon egy D-Bus aktiválást? Máshogy megfogalmazva: mennyivel van jobban akadályozva akárki, hogy írjon egy alternatív implementációt, mint amennyire az inetd-nél vannak?

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

>Tehát ami egy mondattal fentebb újítás volt,

lehet nem fogalmaztam elég hupkompatibilisan ezért még egyszer:
-nem maga a DBus aktiválás volt itt az eredetileg általam szóvá tett probléma, hanem az, hogy így mindenféle menedzselés nélkül indulhatnak daemon processek, amire poetterix megoldása az volt, hogy belegyógyította a dbusba a systemd supportot

>Hint: a DBus-t NEM Poettering csinálta (a specifikáció 6 szerzőjéből csak 2 Red Hat-os).
>HOGYAN akadályoznak meg akárkit, hogy implementáljon egy D-Bus aktiválást?

blacky pls

szerk: közben láttam hogy más is belefutott a problémába:
http://homepage.ntlworld.com/jonathan.deboynepollard/Softwares/nosh/avo…

The obvious thing to do is for the bus controller dæmon to hand off the task of starting and managing these dæmons to a dæmon management subsystem. Unfortunately, despite several such mangement systems having been in wide use since the 1990s and the turn of the century, the writers of D-Bus didn't make it capable of talking to any of them. They didn't even include upstart. The writers of upstart patched D-Bus to know about upstart job files, but the improvements never made it into D-Bus proper. Lennart Poettering explicitly blocked them in 2011.
The System Desktop Bus has but just two modes of operation:
-the non-systemd mode, where the bus controller dæmon tries to spawn dæmons itself, with a helper program that goes and looks up the appropriate (D-Bus) .service file
-the systemd mode, where the bus controller dæmon talks the idiosyncratic systemd protocol to systemd and tells it to start the relevant dæmon(s)

...

the ideal would be a consistent and generic service activation approach which does not require hard-coding particular init daemon names anywhere.

Nagy B és nagy Y pls...

A bug reportra: ha túljutsz a címsoron, néhány érdekesség: a beküldés ideje február 23. A beküldő személye Simon McVittie (Collabora, Debian), aki Scott James Remnant (a linkeld thread-et végigolvasva épp akkortájt hagyta ott a Canonicalt) patcheire hivatkozik. A levlista szálban érkezett utolsó levél január 5-i. És egyébként mindkét patch-készletre Lennard korrektül válaszolt (elvi és implementációs problémákra felhívva a figyelmet, pl. hogy a küldött patchel ha bármi D-Bus szolgáltatás nem tud elindulni akármi miatt, akkor 2 perces várakozás és timeout hiba lesz belőle, hogy egy helyen meg is töri D-Bus config fájl specifikációt stb.). Miután megnyitották a bug report-ot, Lennard annyit írt, hogy mielőtt az új systemd aktivációs séma el nem készül, ne merge-ljék a patcheket (azt nem tette hozzá, hogy amik továbbra is eléggé problémások). És ezután Scott volt az, aki eltűnt, miután megismerte az új terveket.

Vagyis építőjellegű kritikával hozzájárult az Upstarthoz, aztán időt kért, a patch készítője eltűnt, és ezért a systemd és Poettering a hibás? Pls... meg kellett volna írnia az Upstart patchet, vagy mi?

the ideal would be a consistent and generic service activation approach which does not require hard-coding particular init daemon names anywhere.

És ez ellen Poetteringnek sem volt kifogása (lásd a levlista), csak annyit tett hozzá, hogy az ActivationRequest mellett a korábbi SystemdService nevet _IS_ vizsgálják visszafelé-kompatibilitás miatt, mivel több upstream már szállított ezt tartalmazó service fájlokat.

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Próbáltak azóta patchet küldeni? Próbált bármelyik másik init rendszer, pl. az OpenRC beküldeni patchet? Előkerült mégegyszer az egységes API (bár ez a szemantikai különbségek miatt szvsz. nem játszik, mindegyik init külön code path lenne) és konfig fájl kérdése?

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Fixyou: a Gnome nem a systemd-től, mint init rendszertől, hanem a systemd ernyő alá tartozó egyéb alrendszerektől függ (ezek gyakorlatilag sima D-Bus inicializált szolgáltatások), és AFAIK abból is az egyetlen, ami hard dependency, az a logind (ami egy kernel változtatás [egy cgroup kezelő lehet] miatt függ a systemd-től). Két és fél évvel ezelőttről egy GNOME dev. szvsz. objektív beszámolója: https://blogs.gnome.org/ovitters/2013/09/25/gnome-and-logindsystemd-tho…

És akkor most én is objektív leszek: a systemd deveknek igaza van abban, hogy lehet újra implementálni a logind interfészt systemd nélkül (de nem az ő feladatuk, többen meg is csinálták), sokaknak meg igazuk van abban, hogy de ott egy változó interfészre kellene lőniük (és valóban, időnként változik a logind felülete).

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

( nikin v | 2016. 05. 31., k – 09:49 )

Na ez hány ezer backuppot fog hazavágni a világon?
És a fejlesztők kicsit el vannak tévedve. Biztosítani a beállítást amivel minden user process kilőhető az fejlesztés.
Defaultá tenni miközben az eredeti bugreport konkrétan leírja a screenes problémát és más megoldást javasol ...hát had ne mondjak semmit.

https://github.com/systemd/systemd/issues/2900

### ()__))____________)~~~ ########################
# "Do what you want, but do it right" # X220/Arch

Azért lássuk be, rég rossz, ha a backup processzed attól függ, hogy van-e interaktív bejelentkezése vagy annak egy maradványa a usernek... mert ez pl. azt jelenti, hogy ha újraindítod a gépet és elfelejted visszakapcsolni a back-up rendszered, akkor nem lesz back-upod.

Back-up menjen timerből indított systemd serviceből, cronból, sima service (legyen az az /etc/init.d alá bedobott sh vagy natív systemd szolgáltatás) ami folyamatosan tétlenül várakozik, amikor épp nincs rá szüksége, de ne azért menjen, mert a bela az exit előtt elindította...

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Torvalds is megmondta, a Linux azért nem terjed desktopon, mert a distrók leszarják a kompatibilitást, saját magukkal is, ezért eddig sem nagyon lehetett konzisztensen működő alkalmazásokat binárisban terjeszteni Linuxon, ami pedig jelentős "blokk" a fejlesztőknek, ráadásul szembemegy Linus "do not break userspace" elvével, ami a No.1. prioritás a kernelben. "If you use a bug to do something useful, it is no longer a bug, but a feature." Most a systemd ezt olyan szintre emeli, hogy már az userek scriptjeit is eltöri, és a sok nagyonokos meg még meg is indokolja, hogy ez így remek.

A mindenki által leköpködött Win95-ben annó egy rakás spéci kód volt, hogy a korábbi alkalmazások menjenek és iszonyatos hangsúlyt fektettek erre. Ma meg már ha egy rendszer eltöri egy esetleg évek óta jól működő scripted és konfigod, akkor te vagy a hülye. Idáig fejlődtünk 20 év alatt...

-=- Mire a programozó: "Na és szerintetek ki csinálta a káoszt?" -=-

Mondjuk nekem korábban is feltűnt, hogy egyes esetekben mintha a 'változás a változás kedvéért' lenne a motíváció.

Pl. néha már azt is kétlem, hogy a grub-bal indított kernel jobban performál, mint a lilo-val indított. Vagy hogy az 'ip interface add' hatására gyorsabb lesz a hálókártya, mint az 'ifconfig up' hatására.

A mindenki által leköpködött Win95-ben annó egy rakás spéci kód volt, hogy a korábbi alkalmazások menjenek és iszonyatos hangsúlyt fektettek erre.

Sőt, utána is, aztán valahol a 7 környékén rájöttek, hogy egyszerűbb inkább ingyen adni egy virtualizálható XP-t (abban még azért ott voltak ezek nem-NT kerneles legacy kompatibilitási hackek), mint fenntartani a látszatát, hogy lehet bugra alapozni fejlesztést (mert hogy minden ilyen hack újabb code path-et jelent, amit tesztelni kell, és növeli az egész rendszer komplexitását). Aztán nézd meg a Win10-et, ahol már tudnak úgy dönteni, hogy valami nagyon nem kompatibilis és inkább kuka.

Most a systemd ezt olyan szintre emeli, hogy már az userek scriptjeit is eltöri, és a sok nagyonokos meg még meg is indokolja, hogy ez így remek.

Mutass már egy scriptet, amit a systemd (?) tör el, kérlek.

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Vagyis te használnál egy olyan feature-t, ami másnál biztonsági kockázatként is megjelenhet (random user bármi szemetet otthagyhat a gépen futni). És adnak négy lehetséges megoldást, hogy működésre bírd:
1. systemd-run-nal futtatod (kifejezetten a saját felhasználódnak engedélyezed erre az egy feladatra)
2. loginctl enable-linger-rel engedélyed a felhasználódnak, hogy megmaradjanak a cuccai (saját felhasználódnak engedélyezed úgy általában)
3. logind.conf-ban átütöd a KillUserProcesses-t 0-ra (a gép összes felhasználójának visszaadod a régi működést)
4. fordítási időben letiltod a teljes funkcionalitást

És az, hogy mi a systemd-logind defaultja, és hogy ahhoz a többi disztró tartja-e magát (Fedora nem kérdéses, RHEL8-ban meglátjuk), egész más kérdés.

Azért egy rétegigény (mert lássuk be, az, a userek többsége nem akar session-ön kívül dolgokat futtatni, cserébe pl. a Debianos bugreportban is írt osztott mondjuk iskolai rendszernél akár biztonsági kockázatot is jelenthet, hogy random usernek még futkosnak processei), több szinten visszakapcsolási lehetőséggel való kikapcsolása nem akkora probléma, mint ahogy többen próbálják itt beállítani.

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Goto square 1 (avagy idézem önmagamat):

Lassan itt lenne az ideje, hogy végre kimondják: emberek, az nem Unix, ez systemd-OS.
A Unix kialakult valamilyenre (főleg sokfélére) az elmúlt ötven évben, a systemd-OS meg most alakul, örüljünk, hogy részesei lehetünk a történelemnek. Akár akarjuk, akár nem.

Szerintem lassan megérjük, hogy lesz benne SSH szerver is. Ha meg az van már benne, akkor shell funkcionaltás is kell bele.
Végül pedig akkor már valami screen/tmux funkcionalitású cuccot is beletesznek.

De persze mindent szigorúan az alapoktól újraimplementálva, mert ők mindent jobban tudnak, és nem követik el ugyanazokat a hibákat, amelyeket az eredeti szoftverek készítői megléptek korábban és ki is javítottak régen.
-------------------------------------------------------------------------------
Az életben csak egy dolog a szép, de az épp nem jut eszembe.

Slackware Linux 14.1 | 3.10.96-janos

A systemd-resolved már réges rég ott van, az ernyőprojekthez tartozó szolgáltatás, senki nem kötelez a használatára.

(hostnamed, timedated, localed, logind, machined, importd, resolved, ... - csak azokat írtam, amiről a systemd oldalon van linkelve On X cikk)

Magamtól, a szálban kicsit fentebb.

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)