Az Ubuntu is systemd-re vált

Címkék

Most, hogy a Debian Technical Commitee végre pontot tett (Bdale Garbee döntő szavazatával) az init vita végére és megszületett a döntés, hogy a Debian systemd-re vált, Mark Shuttleworth bejelentette, hogy az Ubuntu is vált a saját Upstart-ról systemd-re.

Mark kiemelte, hogy az Upstart kiválóan teljesített eddig az Ubuntu kiadásokban (és a RHEL 6-ban is), de mivel a Debian a systemd mellett tette le voksát, és mivel az Ubuntu elég központi tagja a Debian családnak, támogatniuk kell a Debian döntését.

A részletek itt olvashatók.

Hozzászólások

*popcorn*
_____________________________
Powered by 1,3,7-trimetilxantin

Troll on>>
A következő meg majd az lesz, hogy:

Mivel a Gnome3 a Debian-on, a Fedora-ban, az openSUSE-ben, meg nagyjából minden egyéb disztróban kiválóan teljesített, ezért a Unity-t inkább kukázzuk, és visszatérünk Gnome-ra... A Unity-t meg meghagyjuk telefonra, meg tabletre..

Troll off

http://taklertamas.blogspot.com/ ::: http://www.taklertamas.deviantart.com/ :::Be::Shell:::

Amennyire utánanéztem, lehet jobban is járnának vele. A GDM-logind integráció miatt és az ebből származó multi-seat támogatással tippre kb. konfigolás szintjén megoldhatnák, amit annyira akarnak, a dokkolható telefont/tabletet (AFAIK a LightDM nem támogatja a udev/logind alapú multi-seatet).

Szerk.: Ja, és természetesen, hogy pontosak legyünk: a

GNOME 3 "kiválóan" "teljesített"

, de ez továbbra is hitvita, de a trollkodás nem maradhat el.

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

Hitvitának hitvita, de ha megkérdeznél egy keményvonalas Gentoo usert, hogy SystemD, vagy mi, akkor azt mondaná, hogy neki ne automatizáljon semmi semmit, majd ő eldönti, hogy mi mit indítson el, meg mi hova csatlakozzon fel boot alatt...

Amúgy meg tökmindegy, az NSA keze úgyis mindenhova elér. Ha akarnak usákiában valamit, majd megkenik Linust, hogy csináljon egy backdoort a kernelbe (ha egyáltalán ez még nem történt meg ezidáig...), és akkor mindegy lesz, hogy melyik disztró, és mit használ.. Mert ahogy olvasgatom ez a SystemD, nem Systemd szőrözés első sorban a biztonsági rés lehetőségéről szólt.

http://taklertamas.blogspot.com/ ::: http://www.taklertamas.deviantart.com/ :::Be::Shell:::

Aztán linkelném neki a systemd manualt, hogy továbbra is ő dönti el, hogy mi induljon, hogy legyen-e bármi automatizálva :) [a felcsatolások jogosak, ott van jópár, ami kell a systemd-nek, pl. a cgroupfs-ek, a tmpfs-ek néhány helyen stb.]

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

"Amúgy meg tökmindegy, az NSA keze úgyis mindenhova elér. Ha akarnak usákiában valamit, majd megkenik Linust, hogy csináljon egy backdoort a kernelbe (ha egyáltalán ez még nem történt meg ezidáig...), és akkor mindegy lesz, hogy melyik disztró, és mit használ.. Mert ahogy olvasgatom ez a SystemD, nem Systemd szőrözés első sorban a biztonsági rés lehetőségéről szólt."

1:30-tol... :-)

--
Debian GNU/Linux

Nekem ilyen szar nem kell a tabletemre. Az lxde sokkal jobban gazdálkodik az erőforással, némileg átalakítva talán a tableten is jobban menne. Nem a kinézet miatt mondom, mert a fogyasztás miatt. A dwm terén még jobbak a tapasztalataim, de hogy hogyan lehetne kényelmesen használni a tableten, az jó kérdés.

Váltottak volna így is úgy is szerintem, így legalább volt ürügy a saját kölke kukázására.

En pedig biztos vagyok abban (=erosen valoszinusitem), hogy ha a D az Upstartot valasztotta volna, akkor az Ubuntu nem valtott volna. Pl mind a desktop, mind a szerverek koreben az Upstartnak lett volna tobb felhasznaloja. S akkor nem kernek a DE-k a systemd-t PID1-nek, es a demonok melle a keszitoik csomagolnanak Upstart init scripteket. Az anekdotad abszolult nem allja meg a helyet.

Gondolom már érett bennük a döntés, csak a Debian döntése jó alkalom volt bejelenteni, ezért jött ilyen gyorsan az Ubuntu bejelentése is.

Bwahaha, ilyenkor vicces igazan a hivek meggyozodese, miszerint az Ubuntu egy onallo disztro.

Nem tudom, hogy használtad-e a Bazaart, én igen. Jó kis rendszer, különösen akkor, ha nem kell sok extra feature. Például tapasztalatom szerint sokan nehezen értik meg a Git-féle „egy könyvtárban van minden branch és ott váltogatsz” stílust. Plusz egységes felületen, Pythonban lehet bővíteni, ami szerintem a Gitnek még most sem erőssége.
Szerintem a Git elterjedéséhez hozzájárult a kezdeti hype körülötte, pedig eleinte kifejezetten nehézkes volt a használata a kevés user-friendly parancsok miatt.

-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."
rand() a lelke mindennek! :)

Mi is használtuk a bazaart sokáig, igazából csak az volt a baj vele, hogy lassú volt, meg, hogy leállt a fejlesztése, és az újabb dolgok (pl add --patch) nem kerültek bele.

Ha jól emlékszem, amikor az Ubuntu bzr-t választott, akkor még nem volt git, vagy legalábbis nagyon gyerekcipőben járt, a többi, többnyire nem distributed, nyílt verziókezelőhöz (svn, stb.) képest meg klasszissal jobb volt a bazaar.

Amikor mi választottunk verziókezelőt a projekthez (még az ubuntu előtt), akkor is bazaar volt a legjobb választás szvsz, nem is bántuk meg, de persze már vátottunk gitre.

Az, hogy azóta lett egy jobb opció, az egy másik dolog. Szerintem Ubuntunál fognak is váltani git-re 1-2 éven belül.

Érdekes világnézeted van, szerintem az Ubuntu alapvetően egy üzleti vállalkozás, aminek nem hívei, hanem felhasználói vannak. Mint ilyenben, szokás CBA (költség-haszon) elemzést csinálni. Ha tippelnem kellene, akkor:

1. Az upstartnak nagyobb volt a haszna a sysvinit-vel szemben mint a költsége. Ha jól emlékszem, akkor 2009-ben, amikor váltottak, nem volt systemd, de legalábbis egyetlen disztro sem használta.

2. A systemd önmagában nem adott annyi pluszt, hogy az upstart -> systemd váltás költségét megérje (A RedHat szerint adott, az meg egy másik üzleti vállalkozás más elemzőkkel)

3. Ha viszont a systemd konfigokat készen át tudják venni a debiantól, akkor kevesebb költség mellett több előnnyel jár systemd választása.

Oszt ennyi. Az end userek közül meg nagyon-nagyon kevesen faragtak upstart jobot, szóval ők leginkább lesz*rják, hogy mennyire független az Ubuntu, vagy hogy a rendszerük az upstarttól, a systemdtől, vagy attól működik, hogy Shuttleworth minden éjfélkor meztelenül, egy kakas vérével összekenve fut egy kört a háza körül.

A Ubuntu es a Debian kapcsolatarol pl egy IMO hasznos es valosaggal sokban egyezo velemeny:

"For those who are not familiar with the relationship between Ubuntu and
Debian, I think some history may be helpful here.

Canonical was started largely by long-time Debian contributors who had
been responsible for core portions of the Debian project. Those
contributors had often accumulated, over time, a large number of projects
and ideas that they would have liked to do in Debian, but which were never
feasible for one reason or another. One blocker was that no one was paid
directly to work on Debian and therefore few people could devote day-job
amounts of time to hard problems. Another was that Debian was then, and
is even more today, a huge ocean liner of a project with a very bad
turning radius. It's quite difficult to make distruptive changes to
Debian.

Those long-term Debian contributors had a wonderful opportunity in Ubuntu
to try a bunch of things that they'd always wanted to do in Debian, to
have the time and resources to dig into hard problems, and to push
disruptive changes through their entire archive. They had the time to do
things like write a completely new init system from scratch, one that, I
think it's worth remembering, nearly everyone (including the systemd
authors) considered vastly superior to what Linux distributions were using
at the time. And, after doing that work in Ubuntu and working through the
resulting bugs and instabilities, they were often quite excited about the
possibility of integrating that work back into Debian as well. Remember,
most early Canonical developers were Debian developers first, and had and
often continue to have a great deal of loyalty to and enthusiasm for
Debian as a project."

// Russ Allbery https://lists.debian.org/debian-ctte/2014/02/msg00390.html //

(ez az essze most megfeledkezik arrol, hogy a CLA miatt megse tud visszaadni a Canonical, a RH, Fedora, Maemo bar Upstartra valtottak, rogton tovabb alltak systemd-re)

IMO a Canonicalnak nem erdeke rendszerkomponensek szintjen elterni a Debiantol, csak a felhasznaloi elmenyt befolyasolo programokban es eszkozokben. Nem hiszem, hogy ettol ne lennenek onallo disztro.

Persze, hogy nem önálló disztró. Sok fanboy szerint a debian egy ratyi, de az ubuntu egy isten.
Az is lehet, hogy rájött a dél afrikai barátunk, hogy csalánba veri a f@ßát.
Ezer éve tervezem, hogy fedora-ra vagy slacky-re vissza váltok, eddig még a belakott rendszerem szabott gátat.

Ezek szerint az osszes major Linux distro egyet ert abban mi lesz az init rendszer :)

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Nem tetszik nekem a systemd. Nem értek hozzá igazán, közöm sincs hozzá, valójában mindegy is, mert nyilván ezzel is működni fognak a programjaim. De mégsem tetszik. Itt van pl. ez a weboldal. Fel van sorolva kb. 50 funkció, amivel a systemd rendelkezik, de a sysvinit és az upstart nem. Ugye milyen nagyszerű? Ebből is nyilvánvaló, hogy a systemd mennyivel jobb, írja a szerző. Én viszont 50 olyan funkciót látok felsorolva, amivel nem az init (pid=1) processznek kellene foglalkozni. Mér jó pl., ha a systemd átveszi az atd vagy inted szerepét? És rengeteg hasonló. A systemd grafikus UI-ja az annyira kell nekünk? Attól meg baromi boldogok leszünk, hogy a scriptek át vannak írva C-re.

--
ulysses.co.hu

Scripteket nem is kell átírni C-re. A systemd (C-ben, egy helyen implementálva) megcsinál rengeteg mindent, ami miatt nem lesz/nincs szükség init scriptekre (nagy részük kb. most is a pid fájlok rendezgetésével szórakozik, követi, hogy fut-e már példány, chroot-ol, user-t/group-ot állítgat stb.), de akár lehet azokat is használni (bármilyen futtathatót). Ha meg az extrább funkciókat is ki akarja használni egy szolgáltatás, akkor kell C-ben néhány systemd-specifikus dolgot beletenni (ha jól rémlik a Unix-socket-aktivált szolgáltatásoknál pl. valamit mókolni kell a kódon)

mrev: http://www.freedesktop.org/wiki/Software/systemd/ itt linkelik a The systemd for Administrators Blog sorozat mindegyik részét, azokat érdemes átnézni, hogy mit is tud igazán a systemd. Szerk: De egy példa (és ez mutatja, hogy miért linux-specifikus a systemd): ott van a cgroup szerinti processz követés, ami első ránézésre egy jó ötlet, mert így garantáltan mindig azonosítható, hogy mihez tartozik egy-egy processz. Második ránézésre még jobb, mert pont emiatt akármelyik szolgáltatáshoz megadhatod, hogy akkor ez most a CPU-ból mennyit kapjon (akár hogy melyik core-okra, akár, hogy azon belül milyen arányban), mennyi memóriát használhasson etc.

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

Ezt tudom. Ezzel együtt hamár kb mindenki azt használja, nem értem, hogy az adminoknak szóló doksi mi a francért egy rohadt blogban van, amiben lokálisan ráadásul merő rettenet megtalálni a darabjait. Egyszerűen nem értem, miért nem lett még kiszedve valami értelmes helyre.

(Mondjuk nem néztem még, de gondolom az RH7 doksiban csak benne lesz értelmesen)

Amennyire átfutottam, amikor láttam, hogy már fenn van a 7-es béta doksija, leginkább a korábbiaktól való eltérésekre koncentrál, olyan szintű "mesélős" leírás, mint a fenti blogsorozat nincs benne (cserébe a further reading-nél linkelik a systemd freedesktop-os oldalát...): https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_L…

Szerk.: Amúgy a man oldalai többnyire rendben vannak, és nem systemd-specifikus, hogy van nagyon részletes doksi, csak man oldalak mögé "elrejtve", globális képet pedig az egész működéséről nem nagyon kapsz.

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

Kar, hogy az idezett cikk fele suletlenseg, es az egesz mogott annyi van, hogy az iroja annyira utalja a systemdt, hogy bele se gondol, hogy esetleg nem teljes inkompetenciabol van benne ugy megvalositva egy-egy dolog, ahogy. Nem mondom, hogy tokeletes a systemd, sot... de a linkelt cikk azert erosen tulzas, megha vannak is benne valosagra utalo nyomok.

--
|8]

Szóval a debiannál meghozták az egyetlen logikus döntést, jó sokáig tartott nekik ezt megszülni.

Ubuntusok meg nyílván nem fognak szopni egy saját init rendszer karbantartásával ha az alapjukat képező distro végre egy modernebb init rendszerre vált.

===============================================================================
// Hocus Pocus, grab the focus
winSetFocus(...)

http://c2.com/cgi/wiki?FunnyThingsSeenInSourceCodeAndDocumentation

Ez miért jön elő minden systemd-s topicban?

Igen, felfogtuk, hogy van valami arc, akinek a véleményére kíváncsiak vagytok és egyet értetek vele (bár nagyjából annyit ír, hogy "jaj-a-systemd-több-dolgot-tud-mint-az-eddigi-init-rendszer-ezért-rossz-és-eleve-a-rohadékok-nem-az-én-libcmet-használják-pedig-az-milyen-jó"), de minden hírhez már sok...

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

Mielott telefrocskolod betukkel a kepernyot, azert el is olvashatnad. Felmerulhet, hogy ezt egy masik ember irta("09 Feb 2014 19:56:09 GMT").
Tehat vegyel vissza, es probald meg ertelmezni, ha sikerul. De latszolag nem sikerult.
Nyugodtan osszekapcsolhatod azzal, hogy miert is kell bele HTTP server es QR kod.
Ha faj az igazsag, azzal meg nem tudok mit kezdeni.

Sejtettem, hogy ebbe bele fogok futni, csak már annyiszor láttam linkelve ezt az - amúgy szerintem tényleg semmit mondó - doksit, hogy most elszakadt a cérna (és teljesen véletlen, hogy ezt pont te kaptad meg, elnézésedet kérem).

Pont a linkelt levlistán beszélték meg, hogy bár alapból le van tiltva a szolgáltatás, opcionálissá kellene tenni - és azzá is tették: HAVE_MICROHTTPD és HAVE_QRENCODE.

És igen, elolvastam azt az írást. Két dolgot ír benne: többet tud, több interfésze van, nagyobb valószínűséggel sebezhető és hogy nem a blogpost írójának a libc-jére tervezték. Az előbbi pedig féligazság, mert nem rendszerben gondolkodik, ugyanis lehet, hogy több mindent csinál a systemd, mint egy SysV init, viszont kevesebbet, mint a SysV init és az eddig használt init scriptek együtt. Így ha van is valahol biztonsági hiba, az pontosan egy helyen lesz, nem szétszórva a rengeteg disztró rengeteg init scriptjének rengeteg verziójában.

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

1) A linkelt bejegyzés speciel csak a PID 1-ként futó résszel foglalkozik, a http szerver/qr kód külön futtatható és külön process.

2) Vagyis azt mondod, hogy azért "broken by design" valami, mert opcionálisan tud valamit, ami valakinek hasznos lehet? Vagy azért, mert a korábbi rendszerek ezt nem tudták és anélkül is elvolt mindenki, tehát felesleges, így az új rendszer "broken by design"?

3) Egy párhuzam: nagyon jól hangzik az OpenBSD-től, hogy istentudja mióta nem volt security bug az alaptelepítésükben. Ami valahol jogos, tekintve, hogy alig van valami az alaptelepítésükben. Akkor az OpenBSD biztonságos? Minden más, ami próbál használható csomagkészletet adni alaptelepítésnek, az broken by design?

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

Nem kell, megteszem én ;)

Recently the topic of systemd has come up quite a bit in various communities in which I'm involved, including the musl IRC channel and on the Busybox mailing list.

A one-man-show libc implementáció és különösen a szinte mindenhol recovery-ként használt shell (tudom-tudom, a 4-8 megás routerekre is Busyboxot szokás tenni) felhasználói nem feltétlenül a systemd célközönsége, bár számukra is hasznos.

While the attitude towards systemd in these communities is largely negative, much of what I've seen has been either dismissable by folks in different circles as mere conservatism, or tempered by an idea that despite its flaws, "the design is sound". This latter view comes with the notion that systemd's flaws are fixable without scrapping it or otherwise incurring major costs, and therefore not a major obstacle to adopting systemd.

A világgal az a baj, hogy hibás. Én is tudok semmit mondó állításokat tenni úgy, hogy az állítást önmagával bizonyítom: a világ nem javítható meg, mert hibás.

My view is that this idea is wrong: systemd is broken by design, and despite offering highly enticing improvements over legacy init systems, it also brings major regressions in terms of many of the areas Linux is expected to excel: security, stability, and not having to reboot to upgrade your system.

Oks, érvelj.

The first big problem: PID 1

On unix systems, PID 1 is special. Orphaned processes (including a special case: daemons which orphan themselves) get reparented to PID 1. There are also some special signal semantics with respect to PID 1, and perhaps most importantly, if PID 1 crashes or exits, the whole system goes down (kernel panic).

Igen, úgy kell megírni, hogy ne crasheljen el. Problem solved?

Among the reasons systemd wants/needs to run as PID 1 is getting parenthood of badly-behaved daemons that orphan themselves, preventing their immediate parent from knowing their PID to signal or wait on them.

Ahogy a lentebb már linkelt "systemd is broken by design is broken by design" cikkben is volt, ez marhaság. Erre a systemd a cgroup-okat használja. Egyszerűen azért PID1, hogy a rendszer teljes futása alatt ő felügyelje a processeket, ő legyen a legelső, aki indul és a legutolsó, aki leáll.

Unfortunately, it also gets the other properties, including bringing down the whole system when it crashes. This matters because systemd is complex.

Bullshit. HA minden feature-je tényleg PID1-ben futna, jogos lenne. De vagy 60 különböző futtathatóból áll szerencsétlen. Igen, több mindent csinál, mint a SysVinit, de nem olyan durva, mint első ránézésre tűnik.

A lot more complex than traditional init systems. When I say complex, I don't mean in a lines-of-code sense. I mean in terms of the possible inputs and code paths that may be activated at runtime. While legacy init systems basically deal with no inputs except SIGCHLD from orphaned processes exiting and manual runlevel changes performed by the administrator, systemd deals with all sorts of inputs, including device insertion and removal, changes to mount points and watched points in the filesystem, and even a public DBus-based API.

AFAIK ezek közül egyedül a DBus-hoz van köze a PID1-nek. Miről beszélünk?

These in turn entail resource allocation, file parsing, message parsing, string handling, and so on.

Jogos lenne, ha mindent újra írtak volna hozzá. De nem, ismert és sokat használt, kipróbált komponenseket/libeket használnak.

This brings us to: The second big problem: Attack Surface

On a hardened system without systemd, you have at most one root-privileged process with any exposed surface: sshd. Everything else is either running as unprivileged users or does not have any channel for providing it input except local input from root. Using systemd then more than doubles the attack surface.

Azon a D-Bus felületen rágódunk, ami csak localban érhető el? Vagy a socketeken, amiket figyel, hogy accept után azonnal átadja a frissen indított szolgáltatásnak? Vagy mi?

This increased and unreasonable risk is not inherent to systemd's goal of fixing legacy init. However it is inherent to the systemd design philosophy of putting everything into the init process.

Bullshit. Nem rak mindent a PID1-be.

The third big problem: Reboot to Upgrade

Fundamentally, upgrading should never require rebooting unless the component being upgraded is the kernel. Even then, for security updates, it's ideal to have a "hot-patch" that can be applied as a loadable kernel module to mitigate the security issue until rebooting with the new kernel is appropriate.

Lehetne vitatkozni ezzel az állítással, de jó, számoljunk egy gépes 24/7 rendszerrel.

Unfortunately, by moving large amounts of functionality that's likely to need to be upgraded into PID 1, systemd makes it impossible to upgrade without rebooting. This leads to "Linux" becoming the laughing stock of Windows fans, as happened with Ubuntu a long time ago.

Három bekezdéssel lejjebb ő maga fogja leírni, hogy ja igen, mégis gondoltak erre. Hupsz.

Possible counter-arguments

With regards to security, one could ask why can't desktop systems use systemd, and leave server systems to find something else. But I think this line of reasoning is flawed in at least three ways:

Many of the selling-point features of systemd are server-oriented. State-of-the-art transaction-style handling of daemon starting and stopping is not a feature that's useful on desktop systems. The intended audience for that sort of thing is clearly servers.

Bullshit, makkoséknak pl. nagyon bejöttek a socket-activated szolgáltatások, Win oldalon is egyre inkább próbálják késleltetni a szolgáltatások indítását etc.

The desktop is quickly becoming irrelevant. The future platform is going to be mobile and is going to be dealing with the reality of running untrusted applications. While the desktop made the unix distinction of local user accounts largely irrelevant, the coming of mobile app ecosystems full of potentially-malicious apps makes "local security" more important than ever.

Mobilon amúgy szintén még fontosabb, hogy on-demand, a lehető legkésőbbi időpontban indítsunk szolgáltatásokat, mert addig se fogyasztják az erőforrásokat. Ami meg a helyi biztonságot illeti, a systemd pont, hogy előrelépés az initscriptekhez képest, mert out-of-the-box hoz rengeteg biztonsági feature-t, amit eddig scriptből kellett több-kevesebb sikerrel implementálni.

The crowd pushing systemd, possibly including its author, is not content to have systemd be one choice among many. By providing public APIs intended to be used by other applications, systemd has set itself up to be difficult not to use once it achieves a certain adoption threshold.

Igen, pl. a CUPS is (amit a Systemd for developers írásban példaként hoztak és nagyon sokat profitált a systemd-integrációból) már el se indul systemd nélkül (hint: NOT). A patch, amit közöl a fenti oldalon úgy kezdődik, hogy #if defined(DISABLE_SYSTEMD).

With regards to upgrades, systemd's systemctl has a daemon-reexec command to make systemd serialize its state, re-exec itself, and continue uninterrupted. This could perhaps be used to switch to a new version without rebooting. Various programs already use this technique, such as the IRC client irssi which lets you /upgrade without dropping any connections. Unfortunately, this brings us back to the issue of PID 1 being special. For normal applications, if re-execing fails, the worst that happens is the process dies and gets restarted (either manually or by some monitoring process) if necessary. However for PID 1, if re-execing itself fails, the whole system goes down (kernel panic).

Mint bármilyen más init rendszernél. Vagy az jobb megoldás, hogy egy update után más fut, mint ami a következő újraindítás után fog futni?

For common reasons it might fail, the execve syscall returns failure in the original process image, allowing the program to handle the error. However, failure of execve is not entirely atomic:

The kernel may fail setting up the VM for the new process image after the original VM has already been destroyed; the main situation under which this would happen is resource exhaustion.

Even after the kernel successfully sets up the new VM and transfers execution to the new process image, it's possible to have failures prior to the transfer of control to the actual application program. This could happen in the dynamic linker (resource exhaustion or other transient failures mapping required libraries or loading configuration files) or libc startup code.

MINT... MINDEN... MÁS... PID1-NÉL.

Using musl libc with static linking or even dynamic linking with no additional libraries eliminates these failure cases, but systemd is intended to be used with glibc.

Jajjuristen, nem az én one-man-show libc-met használják bruruhuhuhuhuhuhuhu.

In addition, systemd might fail to restore its serialized state due to resource allocation failures, or if the old and new versions have diverged sufficiently that the old state is not usable by the new version.

Ahogy a lentebb linkelt doksiban... user/distributor error. (off, de tippre ha akkora frissítés van, hogy cserélik a systemd-t inkompatibilis verzióra, ott kernel update is lesz)

So if not systemd, what? Debian's discussion of whether to adopt systemd or not basically devolved into a false dichotomy between systemd and upstart. And except among grumpy old luddites, keeping legacy sysvinit is not an attractive option. So despite all its flaws, is systemd still the best option?

No.

None of the things systemd "does right" are at all revolutionary. They've been done many times before. DJB's daemontools, runit, and Supervisor, among others, have solved the "legacy init is broken" problem over and over again (though each with some of their own flaws).

Igen, a legacy init broken. Igen, lélegeztetőgépen tartotta kismillió másik projekt, amik a hiányosságait pótolták. Igen, ezen funkcionalitások egy részét átvette az Upstart és a systemd.

Their failure to displace legacy sysvinit in major distributions had nothing to do with whether they solved the problem, and everything to do with marketing. Said differently, there's nothing great and revolutionary about systemd.

De: valaki végre merte dobni a cross-platformságot és elkezdte kihasználni a kernelben levő képességeket. Eddig is voltak cgroup-ok, eddig is lehetett pl. erőforrásokat limitálni vele (lásd: janoszen írását) - a systemd mindenki mással ellentétben elkezdte felhasználni bármiféle fallback nélkül. Nem portolható? Nem. Ígyjárás.

Its popularity is purely the result of an aggressive, dictatorial marketing strategy including elements such as:

Engulfing other "essential" system components like udev and making them difficult or impossible to use without systemd (but see eudev).

Ez jogos, tényleg átvett néhány projektet.

Setting up for API lock-in (having the DBus interfaces provided by systemd become a necessary API that user-level programs depend on).

Így legalább lesz egy API, ami ráadásul publikus és bárki újraimplementálhatja. De maradhatunk ott is, hogy a villogó prompt előtt ülve azon kell gondolkozni, hogy akkor itt most csak a linkelés működik, vagy van chkconfig vagy itt rc-update vagy update-rc.d kell.

Dictating policy rather than being scoped such that the user, administrator, or systems integrator (distribution) has to provide glue. This eliminates bikesheds and thereby fast-tracks adoption at the expense of flexibility and diversity.

Ami igaz is lenne, ha nem lenne annyira moduláris, mint amilyen.

So how should init be done right?

The Unix way: with simple self-contained programs that do one thing and do it well.

and do it well, ő mondta.

First, get everything out of PID 1:

The systemd way: Take advantage of special properties of pid 1 to the maximum extent possible. This leads to ever-expanding scope creep and exacerbates all of the problems described above (and probably many more yet to be discovered).

The right way: Do away with everything special about pid 1 by making pid 1 do nothing but start the real init script and then just reap zombies:

#define _XOPEN_SOURCE 700
#include
#include

int main()
{
sigset_t set;
int status;

if (getpid() != 1) return 1;

sigfillset(&set);
sigprocmask(SIG_BLOCK, &set, 0);

if (fork()) for (;;) wait(&status);

sigprocmask(SIG_UNBLOCK, &set, 0);

setsid();
setpgid(0, 0);
return execve("/etc/rc", (char *[]){ "rc", 0 }, (char *[]){ 0 });
}

Yes, that's really all that belongs in PID 1. Then there's no way it can fail at runtime, and no need to upgrade it once it's successfully running.

És akkor építsünk kártyavárat a szolgáltatások követésére, mert a saját tagmondatát ("do it well") elfelejtette.

Next, from the init script, run a process supervision system outside of PID 1 to manage daemons as immediate child processes (no backgrounding). As mentioned above are several existing choices here. It's not clear to me that any of them are sufficiently polished or robust to satisfy major distributions at this time.

És funkcionalitást vesztesz a systemd-hez képest, vagy ha nem, akkor kapsz egy kártyavárat, de legalább a PID1-ed rövid.

But neither is systemd; its backers are just better at sweeping that under the rug.

Igen, az összes disztribútor meg hülye és nem tűnt fel nekik.

What the existing choices do have, though, is better design, mainly in the way of having clean, well-defined scope rather than Katamari Damacy.

If none of them are ready for prime time, then the folks eager to replace legacy init in their favorite distributions need to step up and either polish one of the existing solutions or write a better implementation based on the same principles. Either of these options would be a lot less work than fixing what's wrong with systemd.

Whatever system is chosen, the most important criterion is that it be transparent to applications. For 30+ years, the choice of init system used has been completely irrelevant to everybody but system integrators and administrators.

És harminc alatt semmi nem változott, még mindig a kockás füzetben vagy a PDP-9-en kódoljuk a biteket, jó nekünk az ma is. De komolyan: hány démon, init script, program, stb. tud usert váltani? Hány tud group-ot váltani? Hány kalapál magának saját chroot-ot? Maradhatunk ott, hogy ezeket újra és újra lekódoljuk, csak értelme nincs sok.

User applications have had no reason to know or care whether you use sysvinit with runlevels, upstart, my minimal init with a hard-coded rc script or a more elaborate process-supervision system, or even /bin/sh. Ironically, this sort of modularity and interchangibility is what made systemd possible; if we were starting from the kind of monolithic, API-lock-in-oriented product systemd aims to be, swapping out the init system for something new and innovative would not even be an option.

Megintcsak: egyedül a kényelmi szolgáltatásaihoz ad programozóknak API-t, az alkalmazás döntése, hogy azokat használja-e és még ha használja is, akkor is lehet függetlenné tenni a systemd-től (lásd a fent linkelt systemd for developers cikket), ha nincs szükség a systemd nyújtotta előnyökre.

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

Olyan igazi kommunas szajizuek a kommentek.

Fuck you. Smug shitfaced fuck. I do NOT want to use systemd, learn systemd, or have anything to do with that standard-oils-esque octopus. FUCK YOU. You seek to force us all to adopt it or get out of linux. FFUUCCKK YYOOUU

In short, go and fuck yourself you smug scumbucket

Fuck you. I don't love you. I might like to love your young daughters though. But you'd be against that, and so would alot of liberated women of the west. In that, you would be my enemy.

If you are not a fan of systemd please voice your opinion by emailing debian: 727708 at bugs.debian.org, debian-devel at lists.debian.org. Also ask a debian developer to call a General Resolution to overturn this decision.

No, please don't spam this bug even further. We already considering blocking everyone not in the TC being allowed to post to this bug report.

Go ahead and ban everyone you piece of shit. 727708 at bugs.debian.org, debian-devel at lists.debian.org. Let your voices be heard.
SystemD is a hostile takeover.

Name calling will not help your cause … and if you don't consider systemd a viable option, why the hell didn't you complain earlier?

We've been complaining since 2011. You systemd fucks just dismiss all our complaints. You need a boot through the skull. Maybe you'd get it then.

Awww. are we hiding behind some anonymous ID again? how cute. And yeah, we dismiss complaints when they contain no substance beyond "it does too much" when those features are a simple necessity to get a sane system. Particularly when these complaints come from trolls like you. Too bad. Grow up.

We need to get you, you shitbag. You're not anonymous I take it. If I ever meet you I will beat you.

Es a kommuna igazi "ereje" is elojon:

Debian may need to be forked.

Let the duplication of efforts begin :) Es egyebkent mirol is van szo? Hogy milyen process fogja total eszrevehetetlenul a hatterben elinditani a tobbi process-t, vilagkatasztrofa! \o/ Na ezert tart ott a Linux, ahol. Amiert ilyen total jelentektelen marhasagokon evekig kepesek gorcsolni, vitatkozni, forkolni, kereket ujra feltalalni meg egymast kurvaanyazni, ahelyett, hogy barmi ertelmessel basznak el az idot. Hja, igen, tudjuk, megteheti, miert faj ez nekem? Nem, nem faj, mindenki ugy baszik ki magaval, ahogy jol esik. Nekem meg olyan velemenyem lehet es lesz is rola, amilyen jol esik :)

Ha valaki türelmes, összefoglalná röviden, magyar nyelven, mi a baj a systemd-vel?

Fedorán szokott működni, de mégis jó volna tudnom, miért aggódjak. Tényleg érdekel, mi az, ami miatt egymásnak feszülnek emberek ebben a kérdésben.

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

Az a legfőbb baj vele, hogy mindent asszimilál, mint a Borg :D Lassan bele fogják integrálni a grafikus rendszert és csinálnak egy saját DE-t, irodai programcsomaggal. :P Felker legnagyobb baja az, hogy a biztonsággal kapcsolatos szakemberek szerint az egyszerűség a biztonság kulcsa, minél többet tud valami, annál valószínűbb, hogy hiba lesz benne. És ez egy ilyen alapvető rendszerfolyamatnál nagyon veszélyes. Én speciel egyetértek vele. Bár még nem néztem meg részletesen, hogy melyik feladatot melyik processze végzi, de van benne veszély egy keveset tudó megoldáshoz képest, az szinte biztos. Biztonsági és üzembiztonsági egyaránt.

Egyetértek az álláspontoddal. Ezek után az nem világos számomra, hogy egy olyan cég, mint a Red Hat egyik vezető fejlesztőjének - Lennart - ez miért nem evidens. Mellesleg magam is jobban szeretem az olyan rendszereket, amelyek működését intuitív módon meg lehet érteni, követni lehet.

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

Bár én sem vagyok nagy híve az egy mindent visz megoldásoknak, azért a képet némiképp árnyalja, hogy
-Lennarték azért magát a systemd suitot első bliccre viszonylag modulárisra tervezték, van belül privilage separation, meg vagy kb 60 bináris, amik többé kevésbé a "csinálj egy dolgot, de azt csináld jól" elv alapján vannak összerakva, a systemd sok szempontból esernyőprojekt.
-Ugyan tényleg van egy csomó funkció benne a keveset tudó régi inithez képest, viszont ne felejtsük el, hogy ezeket eddig is csináltuk. Csak random hackolt shell scriptekkel, meg külön daemon felügyelő izékkel, meg egyéb más csengettyűcskékkel, változatos minőségben. Ezekre mondják a srácok azt, hogy ennek tulajdonképp alapnak kellene lennie, és azért ebben van igazság, nem véletlen akarják egy csomóan használni.

Őszintén szólva elég szkeptikus voltam a dologgal kapcsolatban én is elsőre, de kicsit jobban megnézve nem annyira gáz a helyzet. Ami leginkább jogos kritika, az az, hogy tényleg helyenként meg lehetne próbálni formalizáltabb apikat nyújtani. mert a systemd kb szarik egy csomó minden másra a létező FLOSS ököszisztémában, és mikor mondjuk a gnome elkezd dependelni arra az alapszolgáltatásra, amit ő nyújt, akkor a BSDs srácok szopnak a linux only technikával (tegyük hozzá, hogy nem először). Nem tartom szerencsésnek, ugyanakkor az is igaz, hogy nehéz haladni értelmes tempóban úgy, ha nem szabad soha semmit összetörni, mert akkor másnak kényelmetlen lesz. Spec ezügyben tök értem az RH álláspontját, hogy leszarja, hogy mondjuk a freebsdnek ettől dolgozni kell, neki a saját ügyfelei fontosak.

Szóval szerintem itt inkább ilyesmikkel van a baj, technikailag a projekt első bliccre meglehetősen rendben van.

Ami leginkább jogos kritika, az az, hogy tényleg helyenként meg lehetne próbálni formalizáltabb apikat nyújtani. mert a systemd kb szarik egy csomó minden másra a létező FLOSS ököszisztémában, és mikor mondjuk a gnome elkezd dependelni arra az alapszolgáltatásra, amit ő nyújt, akkor a BSDs srácok szopnak a linux only technikával (tegyük hozzá, hogy nem először). Nem tartom szerencsésnek, ugyanakkor az is igaz, hogy nehéz haladni értelmes tempóban úgy, ha nem szabad soha semmit összetörni, mert akkor másnak kényelmetlen lesz. Spec ezügyben tök értem az RH álláspontját, hogy leszarja, hogy mondjuk a freebsdnek ettől dolgozni kell, neki a saját ügyfelei fontosak.

Welcome to the world of freedom of choice.

Ugye a kernel betöltödik, ez oké. Szerintem ezután csak a legfontosabb dolgoknak kelllene betöltödni, lefutnia. Aztán bejelentkezéskor ami az user fiókhoz tartozik.
Az otthoni pécék és a szerverek közt azért van különbség. A szerverekhez kell az, hogy bejelentkezés nélkül is működjenek a dolgok, ezért is vannak démonok.
Én is az mellett vagyok, hogy legalább a terminált lehessen futtatni, ez minél hamarabb legyen elérhető. Mert ha valami gond van a betöltés során, helyre tudjuk állítani a rendszert. Az is jó, ha a bootmenedzserben elérhető rendszergazdai helyreállító opció, bár lehetőleg bootoláskor ne hasaljon el a rendszer semmi miatt se.

Kérdés: csak én képzelem, hogy van némi hasonlóság a systemd egyes részei és a milliószor elátkozott inetd között?