debianfork.org - Újabb tiltakozás a Debian systemd tervei ellen

Debian

A Debian az év elején hosszas vajúdás után meghozta a döntést: systemd-re vált. Vannak, akik azóta sem nyugodtak bele ebbe a döntésbe. Ian Jackson egy újabb GR javaslatot-t indított az "init rendszer-választás szabadságának megőrzése" címmel, amelynek nyomán hosszas levelezés alakult ki.

Vannak, akik továbbmentek. "Veterán UNIX adminok" egy csoportja - nyilvánvalóan nyomásgyakorlás céllal - létrehozta a debianfork.org weboldalt, ahol arra biztatják a Debian fejlesztőket, hogy azok támogassák Ian Jackson javaslatát.

Mint írják, nem akarják, hogy rájuk kényszerítsék a systemd használatát, mert az a UNIX filozófia elárulása.

A debianfork.org-on azzal összegezték megmozdulásukat, hogy ha a Debian-ban a systemd leváltja a sysvinit-et, akkor forkolják a disztribúciót és sajátot hoznak létre. Remélik, hogy nem jutnak el idáig, de mint írták, felkészültek erre az eshetőségre is.

( asola | 2014. 10. 20., h – 09:54 )

Jól felhúzták magukat :)

Mondjuk nekem sem tetszik a giga-monolitikus-mindenbe-beleavatkozó init rendszer gondolata.

( BikMak | 2014. 10. 20., h – 10:05 )

Nincs nagy kedvem belemélyedni a témába, úgyhogy valaki összefoglalná, hogy miért rossz (vagy miért nem) a systemd?

Amikor tavaly az Archlinux áttért systemd-re én vettem a fáradságot és utánanéztem a dolgoknak és azóta is minden szerveren és desktopon is systemd-t használok, és eddig még egyszer sem volt vele semmi gondom, egyedül a journallog nem tetszik, de azt meg egy ForwardToSyslog=yes megoldja. Értem én, hogy "systemd betrays the UNIX philosophy", de mint tudjuk "Linux Is Not UniX".

ja igen, csak gondolod. hiába állítod be, journald továbbra is gyűjti a logokat..

Ez persze akkor igaz, hogy ha alapból csak journald van a rendszeren és később akarsz [r]syslog-t használni. :(
--
A legértékesebb idő a pillanat amelyben élsz.
https://sites.google.com/site/jupiter2005ster/

Mi a baj a journallal? syslog futhat mellette side-by-side, es megkonnyiti a syslogd dolgat, az altala gyujtott logok by default nem tarolodnak lemezen, es a memoria hasznalatat is le tudod redukalni kozel nullara. Cserebe megkapsz olyan josagokat, hogy systemctl status-ban latszik a service utolso par logsora. Ennyit szerintem boven meger ez a kis "kellemetlenseg".

--
|8]


# systemctl status i8kmon
● i8kmon.service - LSB: Dell fan/cpu-temperature monitor
   Loaded: loaded (/etc/init.d/i8kmon)
   Active: failed (Result: exit-code) since Mon 2014-10-20 15:04:33 CEST; 33s ago
  Process: 6669 ExecStop=/etc/init.d/i8kmon stop (code=exited, status=0/SUCCESS)
  Process: 16603 ExecStart=/etc/init.d/i8kmon start (code=exited, status=1/FAILURE)

Oct 20 15:04:33 eowyn i8kmon[16603]: Starting Dell fan/cpu-temperature monitor: i8kmon Could not find /proc/i8k. failed!
Oct 20 15:04:33 eowyn systemd[1]: i8kmon.service: control process exited, code=exited status=1
Oct 20 15:04:33 eowyn systemd[1]: Failed to start LSB: Dell fan/cpu-temperature monitor.
Oct 20 15:04:33 eowyn systemd[1]: Unit i8kmon.service entered failed state.

Vagy epp egy teljesen jol mukodo service: 


# systemctl status postfix
● postfix.service - LSB: Postfix Mail Transport Agent
   Loaded: loaded (/etc/init.d/postfix)
  Drop-In: /run/systemd/generator/postfix.service.d
           └─50-postfix-$mail-transport-agent.conf
   Active: active (running) since Sat 2014-10-18 12:57:54 CEST; 2 days ago
   CGroup: /system.slice/postfix.service
           ├─ 1016 /usr/lib/postfix/master
           ├─ 6579 qmgr -l -t unix -u
           └─17898 pickup -l -t unix -u -c

Oct 20 10:06:27 eowyn postfix[5426]: Reloading Postfix configuration...done.
Oct 20 10:07:56 eowyn postfix/master[1016]: reload -- version 2.11.1, configuration /etc/postfix
Oct 20 10:07:56 eowyn postfix[6451]: Reloading Postfix configuration...done.
Oct 20 10:07:56 eowyn postfix/master[1016]: reload -- version 2.11.1, configuration /etc/postfix
Oct 20 10:07:56 eowyn postfix[6564]: Reloading Postfix configuration...done.
Oct 20 12:26:46 eowyn postfix/pickup[5061]: A3EB73E157E: uid=1000 from=<algernon>
Oct 20 12:26:46 eowyn postfix/cleanup[11513]: A3EB73E157E: message-id=<1413800806-3161-bts-algernon@madhouse-project.org>
Oct 20 12:26:46 eowyn postfix/qmgr[6579]: A3EB73E157E: from=<algernon@madhouse-project.org>, size=497, nrcpt=1 (queue active)
Oct 20 12:26:46 eowyn postfix/smtp[11521]: A3EB73E157E: to=<control@bugs.debian.org>, relay=10.242.42.1[10.242.42.1]:25, delay=0.29, delays=0.03/0.01/0.15/0.1, dsn=2.0.0, s...8D83A108FBB)
Oct 20 12:26:46 eowyn postfix/qmgr[6579]: A3EB73E157E: removed

--
|8]

Hat csak arra gondoltam h a debian az: Debian GNU/Linux, Debian GNU/BSD, Debian GNU/HURD, szoval lehet akar a debiannak semmi koze se a linuxhoz.
A debian az debian.
A linux distribuciok lehetnek olyanok amilyenek, a debiant az elvei es a jellege miatt vhogy kozelebb erzem egy unix rendszerhez mint egy jott-ment linux disztrot.
ok, hogy egy linux disztrora ra lehet mondani h not unix mert miert kellene ragaszkodnia hozza, de azert a debiannal ez nem annyira egyszeru dolog.
egy linux distro felepulhet akarhogy is, pl az android drasztikusan at lett alakitva, de a debian az debian, ne keverjuk ossze akarmelyik jott-ment linux disztribucioval, mert nem az.
es ez a valtoztatas elegge a debian lenyegi reszehez tartozik.

amugy en nem tudok donteni meg a ketto kozott (jelenleg sysvinit mukodik nalam a debianomba (desktop))

amugy van egy latvanyos pelda fork-ra a KDE eseteben.
a nyilt SW vilag ugylatszik marcsak ilyen.
kijott a KDE4, de a KDE3 el tovabb Trinity Desktop Environment (TDE) neven, ez egy nem hivatalos forkja a KDE-nek. (jelenleg en pl a trinity-t hasznalom, bar valtani szeretnek sawfish-re)

A Hurdot hagyjuk, játék, az is marad, a kfreebsdt meg emlékeim szerint épp megfenyegették, hogy vagy nekiállnak karbantartani, vagy nem lesznek hivatalos port. Szóval a gyakorlatban a nagytöbbségnek a Debian mégiscsak linux.

Tény, hogy komplexebb, mint egy átlagos linux disztró, azt mondjuk nem tudom, hogy mennyire unixabb, mint egy akármi más linux.

Ez a Trinity mennyire élő projekt? Mostanában ugyan nem desktop linuxozom, de a kde4től nem estem hasra, a hármat viszont szerettem...

nem is az erdekes h hanyan hasznaljak, hanem h nem linuxra van fixen epitve mint mas distrok, raadasul azok lehetnek azon tul h linux a magjuk akarmilyenek is, addig a debian mar eleg regota lat el server funkciot, rengeteg serveren az volt evekkel ezelott (mostanaban nem tudom mi a helyzet), el tudom kepzelni h egesz kis szubkulturaja van, raadasul rengeteg linux distronak ez az alapja, gyakorlatilag a fel linux vilagnak
szoval ez amolyan unix szerintem

nem tudom h komplexebb e mint mas distro, inkabb rossz megkozelites ez

ugy tudom h elo project ez a trinity, bar en nem is nagyon frissitgetek, le vagyok maradva, nalam meg mindig a squeezy van egyebkent.
ncore forumon is megemlitettem, ott vki vmi live valtozatot probalt ki(tetszett neki), nem tudom mirol beszelt, en nem kerestem, ezexerint van ilyen is, mondta h telepiteni is fogja...

http://en.wikipedia.org/wiki/K_Desktop_Environment_3#Trinity_Desktop_Environment

http://www.trinitydesktop.org/

Azért az igazság az, hogy eredetileg linux disztró volt, és lényegét tekintve most is az, a fő szempontokat az diktálja. Mivel egyébként egy elég befogadó projekt, ami azt az elvet követi, hogy aki nem tesz keresztbe másnak, azt szívesen látják, csinálhatja, ami neki kedves. Ezért aztán volt pár ember, aki játszik a hurddal benne, meg a freebsd kernellel. Ez utóbbiak az előző ciklusban elég jól megcsinálták a portolást ahhoz, hogy hivatalos port legyen, viszont mostanra láthatólag elfogyott a lendület, ki is csapták szívbaj nélkül a minap (mármint mint hivatalos portot, természetesen ettől még akinek kedves, csinálhatja, csak nincs központi secupdate és hasonlók). Szóval a debian linux, ami alapvetően csomagolja az opensource világ használható dolgainak nagyrészét.

És persze, sokmindennek alapja, de ettől még nem lesz unixabb, mint akármi más linux, meg azt sem értem, a szerver funkciók hogy jönnek ide.

-- trinity: hát mondjuk a latest news tavaly nyár... :/

Még mindig eléggé leegyszerűsítve: http://boycottsystemd.org/

Volt valamelyik cikkben (amikor még csak elemezgették ezt a lépést) egy részletesebb leírás, hogy mik a gondjaik vele (főleg műszaki érvekkel volt tele), de most nincs kedvem megkeresni.

Zavard össze a világot: mosolyogj hétfőn.

Hupuk nem kepesek tullendulni 1970-en (de legalabb jol elhitetik magukkal, hogy a csillio tonnanyi szemetbol osszecelluxozott ize az "egyszeru"), cserebe akik igen, keptelenek leimpementalni azt jol, amit masok megtettek. "Bar van, akinek mukodik".

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

( atya | 2014. 10. 20., h – 10:22 )

Remélem sikerül visszairányítani a Debiant erről a félelmetesen ostoba útról. Ha nem, akkor én biztosan a fork-ot fogom használni és anyagilag támogatni.

( turul16 v | 2014. 10. 20., h – 10:50 )

subscribe.

Meg egy
- "Rosz mert nem pontosan ugy megy mint 30 eve",
- "Rosz mert lusta vagyok elolvasni a manualt".

Veletlenul sem olyasmi amibol lehetne egy bug report.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

( utpKabel | 2014. 10. 20., h – 10:58 )

Szerintem tökjó a systemd, soha nem bootolt még olyan gyorsan a Linuxom, mint a systemd-vel.

Szerintem tökjó a systemd, soha nem bootolt még olyan gyorsan a Linuxom, mint a systemd-vel.

Tok jo!

Akkor ha fenti kezdemenyezes sikeres, akkor te beallithatod hogy neked a systemd legyen az alapertelmezett init system.

Aki meg nem desktop kornyezetben hasznalja a linux-t az meg beallithatja hogy systemv legyen.(mert vannak userek akiknek k*rvara nem szamit hogy 10 vagy 100 sec a boot, viszont nagyon fontos hogy a rendszer atomstabil legyen, es az utolso ponting manualisan finomhangolhato)

Vannak ilyen általában bejövő jóslatok, hogy a bonyolult dolgok el szoktak romlani. Ráadásul nehezebb bennük megtalálni a hibákat, és ha egyáltalán fény derül rájuk, akkor nehezebb ezeket kijavítani is. Lehet, hogy a tapasztalt adminok és felhasználók nem a tanulástól ódzkodnak (mivel 43768 dolgot megtanultak az elmúlt húsz évben, egyel több vagy kevesebb, édes mindegy), hanem a több százezer soros, mindent magába asszimiláló init bináristól (vagy azok csoportjától, teljesen mindegy), amit olyan hozzáértők fejlesztenek, amilyenek. Szerintem.

1) A systemd nem egy binarisbol all, es nem teljesen mindegy, hogy egy binaris-e vagy sem. Ha mindegy lenne, akkor a sysvinit nagysagrendekkel tobb, es bugosabb kodot tartalmazna.
2) sysvinitet debugolni horror.

A sysvinit scriptekkel megvan az a baj, hogy 90%-uk copy & paste, kb rendszerrol rendszerre mas szokasokkal, megoldasokkal. Nem volt ritka olyat latni, hogy kulon volt RedHates, Debianos meg ki tudja meg milyen init script, mind picit maskepp bugos. Szerintem ez nagyon nem volt jo. De ha neked ez bejott, hat szived joga. En allitom, hogy ertelmes admin nem szereti ugyanazt N felekeppen megcsinalni, inkabb afele hajlik, hogy a dolgok egysegesen mukodjenek.

Hozzatennem, hogy a sysvinitnek tobb "fejlesztoje" van ugyan, mint systemd-nek, leven kb minden init scriptet upstream "fejlesztettek", de ez meg is latszik rajta. Katasztrofalis a legtobb shellben irt init script allapota. Osszessegeben sokkal tobb, es bugosabb sort tesznek ki, mint systemd + unit fileok.

De, ha barkinek az kell, lehet hasznalni, de nehogy mar a systemdseknek kelljen megoldani a sysvinites bugokat, vagy leimplementalni azokat a featureoket, amik systemdben megvannak, epitenek ra masok (pl GNOME), de sysvinit alapokon nincsen megfeleloje.

--
|8]

> Katasztrofalis a legtobb shellben irt init script allapota
+1

Ezzel cluster építésnél lehet leggyakrabban szembesülni, tipikusan a visszatérési értéknek köze nincs a kiírt állapothoz, stop után még másodpercekig vígan fut a service, a start hibaüzenete elnyelődik, stb, stb.

Hasonlóan mókás amikor LXC hoston a service stop nyom egy killall -t, így az összes jailben kinyírja az adott service-t. (Persze ilyenkor mondják azt, hogy az LXC szar, mert miért látszanak a PID-ek. Nem.)

Semmi olyat nem látok a sysvinit-ben amiért meg kéne védeni. Egyedül a megszokás szól mellette.

Pl a nagios-nrpe-server Debian Squeeze-ben még simán killall-ozott stop-nál. Különösebben nem érdekel, hogy ki a felelős érte vagy az összes többi initscript hibáért, csak konzisztens működést akarok. Az a baj, hogy a sysvinit nyitvahagy egy rakat kérdést, amire aztán mindenki feltalálja a saját kreatív megoldását, ami többnyire bugos lesz.
Elvileg működhetett volna jól ez a rendszer, de gyakorlatilag nem működik, minimális az együttműködés a scriptírók között, pedig lett volna idő kialakítani a rendszert (bár Wheezy-n mintha elindult volna valami).

Megoldás nincs, csak eszközök, amiket lehet jól, rosszul és sehogy nem használni. A systemd ezzel szemben szigorúbb választ ad a kérdésekre, kicsavarja a karbantartó kezéből a gányolási lehetőséget, nem csak eszközt ad, hanem azt is megmondja, hogy hogy kell őket használni.

De ne mondd, hogy megkerülöm a kérdést: hogy kezeljük azt, ha egy daemonból több független példány is fut a gépen? Nem az a kérdés, hogy meg lehet-e oldani (meg), hanem hogy hogy. Kb 100 féle módon, ami újabb 100 problémát vet fel.

Naja, beledrózotni, átheftölni. Aztán jön egy upgrade, ami épp egy initscript bugot javít és a megdrótozott verzió meg marad a bugos. Jön egy biztonsági upgrade aminek újra kell indítani daemont, a másodpéldány marad sechole-os. Meg a dist-upgrade pokol.

Miközben így is lehet csinálni (kulcs a %i): 


$ cat /usr/lib/systemd/system/openvpn@.service
[Unit]
Description=OpenVPN Robust And Highly Flexible Tunneling Application On %I
After=network.target

[Service]
PrivateTmp=true
Type=forking
PIDFile=/var/run/openvpn/%i.pid
ExecStart=/usr/sbin/openvpn --daemon --writepid /var/run/openvpn/%i.pid --cd /etc/openvpn/ --config %i.conf

Egy hibas systemd unitot is ugyanugy ki lehet kapcsolni. Sot, az meg a dependenciakat is jobban fogja kezelni.

Es mivel a systemd unitok lenyegesen egyszerubbek, mint az init scriptek, sokkal kisebb a hibalehetoseg is. Magaban a PID1-ben tobb, az igaz, viszont az lenyegesen jobban is van auditalva, mint a sysvinit ugy cakkumpakk. Es meg az a nagy kulonbseg is megvan, hogy a systemd binarisok forrasat azert javareszt egy helyen tartjak, konnyebben hozzaferheto (nem kell osszevadaszni), es nem feltetlen jottment emberek patkoljak, akik epp gyakornokok voltak a cegnel par honapig.

--
|8]

állandóan azzal jönnek h az init scriptek bonyolultak. nem tudom nekem nem. egyszer kell végigolvasni de akkor rendesen és megérted.
a systemd scriptek is mint a faék, de a systemd környezettel egy nagybaj van. folyton többet és többet tolnak bele ami nem is volt az eredeti koncepció része.

lásd: ntp,dhcpd,journald stb....

ha neked jó h kevesebb mint 10 év múlva lesz a monolitikus rendszered és minden a systemd-től fog függni akkor neked is szíved joga használni.
--
A legértékesebb idő a pillanat amelyben élsz.
https://sites.google.com/site/jupiter2005ster/

Akkor meg nem lattal eleg init scriptet, ha ugy gondolod egyszeru. Plane nem tobb, kulonbozo distron. :)

Az meg, hogy minden a systemdtol fugg, nem fog zavarni. Eddig minden a sysvinittol fuggot, nem haltam bele. (Solarisosok sem haltak bele SMF-be, pedig abban meg XML is volt.)

--
|8]

Ezt már elolvastad: http://boycottsystemd.org/

Itt azért elég jól össze vannak foglalva műszaki érvek, hogy miért ne systemd.
Nem állítom, hogy a sysvinit jó.
De azért, mert az vacak, és cserére érett, ne egy másik zsákutcába menjünk, ami most még mézzel szépen le van öntve, de attól alatta még akkor is csak egy kupac szar marad.
Nem néztem utána linuxon az alternatíváknak, de miért nem lehet egy olyan normális dolgot implementálni, mint solarison az smf? Miért kell újra feltalálni a spanyolviaszt?

Mondjuk ha már többen előhozakodtak az SMF-el, akkor felteszem a kérdést: az miért nem ütközik a UNIX filozófiájával? Miért nem tekint rá blob-ként senki (csak mert ha jól felejtek, alatta megmaradt 1 init processz?)? :) Nekem az a benyomásom, hogy épp az egyik ihletője volt a systemd-nek, bár leszögezem, a solarisokat csak kevéssé ismerem, így nincs fogalmam arról, hogy mennyire specializált dolog ez a solaris kernel és/vagy rendszer nyújtotta egyedi lehetőségekhez pl.

Elég hozzá az ls meg a more? Biztos? Mondj egy scenario-t, ahol nem elég elolvasni a megfelelő scriptet, illetve a kellőképp jól irányzott "ls" parancs kimenetét? Kíváncsi vagyok, hol lehet ilyen, amikor a csak szöveges fájlok és symlinkek alapján működő rendszerindításnál ennél többre van szükség :-P

Én ebben maximum azt a problémát látom, hogy nem tudsz rá olyan könnyen egyszerű workaround-ot hegeszteni shell scriptben, mert nem abban készül. Ez viszont nem feltétlen hiba. Eddig boldog-boldogtalan beletúrt az init scriptekbe, ha akart és egy kicsit értett hozzá, systemd-vel ez kicsit nehezebben kivitelezhető. Cserébe jó eséllyel egy ismeretlen rendszeren nem a korábbi rendszergazda tákolmányaival fogsz találkozni, és töltesz el hosszú órákat, hogy kibogarászd mit és miért úgy oldott meg, vagy mit szúrt el.

Úgy látom, hogy nem értjük egymást. Nem olyan hibákról beszélek, amitől nem fog elindulni például a bluetooth a rendszereden. Olyanokról beszélek, ami csak évek (vagy évtizedek) múlva fog kiderülni. Amin keresztül majd bejön a következő APT. És akkor majd hiába mondom, hogy én megmondtam. Abban igaza van algernonnak, hogy kell egy egyszerű, átlátható, praktikus indító rendszer. De nem olyan, amibe mindent bele akarnak szuszakolni, mert abból baj lesz előbb-utóbb. Lényegében minden ilyenben ki szokott derülni hiba. Az a baj, hogy a sok függőség miatt nem lehet elkerülni a használatát, akkor az egyébként sokszínű Linux rendszerek ebből a szempontból vissza lesznek butítva homogénné, ami - mint tudjuk - biztonsági szempontból oltári veszélyes.

Solaris SMF is van egy ideje, abba is lenyegesen tobb dolgot szuszakoltak bele, mint sysvinitbe. Az, hogy tobbet tud, konnyen lehet, hogy meg jo is lesz. Pl a FreeBSD kernel is tobbet tud, mint a 386BSD, de valahogy megis el tudjuk viselni, mert tobb elonye van, mint hatranya. Itt is pont ez a helyzet: nyilvan vannak hatranyai, vannak rizikoi, de tobb elonye van, amik elfogadhatova teszik a rizikot.

--
|8]

FYI, a systemd nem a boot sebessegrol szol. Az egy kellemes mellekhatas lehet (es egy jol tuningolt sysvinit elleneben a systemd minimalisan gyorsabb). Es orulunk, hogy sok a zseni, de en nem vagyok az, meg az emberek tobbsege sem, ezert nekunk messze hasznosabb a systemd. Kinottem mar abbol, hogy hatalmas katyvaszban keressem a tut.

--
|8]

Arról _is_ szól, de valóban nem ez a lényeg - Egybegyúrnak olyan funkciókat, amik jól megvannak külön-külön, újra feltalálják a kereket meg a langyos vizet... Mert a meglévő eszközöket nagyon nem ismerik. Ha neked a shell scriptek rendszere katyvasz, akkor lelked rajta - nekem, meg sok más embernek nem az - egyszer kell megérteni a működést, meg azt, hogy mi mire való. Attól, hogy rengeteg initscript elkövetőjének maximum kapát adnék a kezébe, az más kérdés, abban nem a sysvinit a hibás.

Nem. Attól, hogy valaki nem tud szépen és jól scriptet írni, attól még nem a scripteket felhasználó rendszer a hibás. Anno el kellett követnem néhány nyakatekert ötlet miatt egy-két dolgot Python-ban egy nagy cég egyik tűzfalához. Megcsináltam, ahogy képes voltam rá. Nem lett szép, erősen szuboptimális volt, a megvalósítás sok sebből vérzett - de működött. Nomostan ezért a gányolt valamiért - a te gondolatmenetedet követve - a Zorp is hibás. (Szerintem meg nem az.)

A zorp is gaz, de masert :)

Azert alapveto kulonbseg van a ketto kozott. A Zorp ad neked egy egesz turheto keretet, amibe be lehet illeszkedni, amivel dolgozni lehet. A sysvinit nem ad ilyet, ahhoz ossze kell rakni, ra kell epiteni, igy amit raepitesz, az a rendszer reszeve valik.

--
|8]

Mit nem ad?! Jól definiált folyamatot ad a rendszerindító scriptek futtatásához. Pont. Ennyit, és nem többet vállal ezen a területen. Úgyhogy a "nem ad keretet" felvetés olyasmit kér számont a sysvinit-en, ami by design nincs benne. Ezt viszont baromi egyszerű, átlátható módon teszi. Mégegyszer mondom, hogy azok a scriptek, amik ezt a funkciót használják azok az adott alkalmazás/szolgáltatás részei, nem pedig az init-hez tartoznak, a minőségükért nem az init, hanem a script elkövetője felel.
Az, hogy egyes disztrók milyen közös eljáráskönyvtárat hegesztenek a sysvinit-es scriptek megsegítésére, az az adott terjesztés (és azon belül a sysvinit-hez csomagolt scriptek) karbantartójának a felelőssége. Sajnos bolondbiztos, korrekt hibakezelést, a futás feltételeinek részletes ellenőrzését is tartalmazó indítóscriptből nagyon kevés van. De ez megint csak nem az indítóscriptet meghatározott helyen/időben/paraméterrel lefuttató komponens hibája.
Ha írsz egy scriptet, és berakod a /etc/cron.daily/ alá, és ez a scripted hülyeséget csinál, rosszul működik, etc. akkor az anacron lesz a hibás vagy te?

Jol definialt folyamatot? Merre van definialva? Mert man oldal annyit mond initrol, hogy az inittab alapjan indit. Minden mas, a runlevelk es a tobbi az mar azon kivul van megoldva, tehat igy a te logikad alapjan az sem az init rendszer resze. Innentol baromira nincs jol definialva, mit csinal.

De, lasd pl NevemTeve kommentjet, mely szerint mar a jelenlegi (sysvinit) rendszer is kusza es atlathatatlan. Jol definialt folyamat, bizony.

--
|8]

Mi a praktikus abban, hogy emberórák mennek el arra, hogy egyszerre két formátumú indítóállományokat készítsenek? Értem, freedom, meg ilyenek, de szerintem teljesen időpazarlás.

"Belépés díjtalan, kilépés bizonytalan."
"Vajon mit várok a sorstól, ha hányok az édestől, és izzadok a sóstól."

( artifex | 2014. 10. 20., h – 11:02 )

Csak én érzem már szánalmas ezt a nyűglődést a systemd körül?

"Belépés díjtalan, kilépés bizonytalan."
"Vajon mit várok a sorstól, ha hányok az édestől, és izzadok a sóstól."

Tényleg szánalmas. Csak mert valami más, mint a megszokott, rögtön sírni kezdenek a "nagy" öregek. Én sem tegnap kezdtem a szakmát, de inkább veszem a fáradtságot és újra-meg-újra nekifutok, de akkor is megtanulom, hogy a fenébe működik a systemd. Persze, teljesen más mint a Sys V init, de nem megtanulhatatlan.
Amúgy meg a Sys V init scriptingben is van egy csomó gányolás, mert olyat akartak benne megvalósítani, amit alapból nem tud. (függőségek) A systemd meg tudja.

Ave, Saabi.

A függőségek kezelése by design kimerül annyiban, hogy van indítási sorrend - ha "aaa" függ "bbb"-től, akkor az S##aaa-ban a számnak nagyobbnak kell lennie, mint az S###bbb-ben. Azt, hogy az adott szolgáltatáshoz szükséges másik fut-e, működik-e, azt a szolgáltatásnak magának kell ellenőriznie, mint minden egyéb, a futásához szükséges feltétel meglétét. Az initscript önállóan el kell(ene), hogy tudja dönteni, hogy minden adott-e a szolgáltatás működéséhez, vagy sem. Példának okáért egy olyan szolgáltatásnál, ami NFS-en csatolt fájlrendszert használ, annál az initscriptnek kutya kötelessége meggyőződni arról, hogy az NFS-ről kapott munkakönyvtár létezik-e, és a szükséges jogokkal elérhető-e. Megont csak azt tudom mondani, hogy ha ezt nem csinálja a script Lustilovics elkövetője miatt, az nem az init-megoldás, hanem a script elkövetőjének a hibája.

Azt, hogy az adott szolgáltatáshoz szükséges másik fut-e, működik-e, azt a szolgáltatásnak magának kell ellenőriznie, mint minden egyéb, a futásához szükséges feltétel meglétét.

Es innentol ratyi az egesz, mert kismillio init scriptben lesz ugyanaz implementalva, tobbnyire maskepp, distro fuggoen, es rosszul. Hurra!

--
|8]

Nem a környezetednek kell tudnia, hogy neked mire van szükséged, hanem neked magadnak. Legalább is ha felnőtt ember vagy. Akkor most felnőttnek lenni ratyi? Olyan dolgot vártok el a sysvinit-től, ami by design nincs benne, amit az azt használó scripteknek kell tudnia. (A sysvinit azt vállalja, hogy a megfelelő futási szinten a "K"-val kezdődő scripteket (ez célszerűen symlink a megfelelő scriptre) "stop", az "S"-sel kezdődőeket meg "start" paraméterrel meghívja a K illetve S utáné rész szerint sorbarendezve. Nem szól arról, hogy mi függ mitől. Sőt, a scriptek futtatása nem szól arról, hogy valamit életben kell tartani, ha kidől - erre az inittab való.

Egyébként miért lenne minden scriptben pl. a "van-e hálózat?" újraimplementálva? Maximum azért, mert az adott disztró összeállítója nem csinálta meg egy közös eljáráskönyvtárban, vagy ha megcsinálta, az adott initscript elkövetője nem használja azt.

Nem a környezetednek kell tudnia, hogy neked mire van szükséged, hanem neked magadnak.

Az egy dolog, hogy en tudom, mire van szuksegem. Az egy teljesen masik dolog, hogy ezt nekem kell *minden* init scriptben leellenoriznem.

Olyan dolgot vártok el a sysvinit-től, ami by design nincs benne, amit az azt használó scripteknek kell tudnia.

Nem varom el a sysvinittol. Tudom, hogy nem tudja, es nem is tudhatja. En azt allitom, hogy a systemd azert (is) jobb, mert tudja ezt. Tobbet nyujt, kenyelmesebben, nekem. Ettol nem lesz rossz, azert mert okosabb.

Egyébként miért lenne minden scriptben pl. a "van-e hálózat?" újraimplementálva?

Mert minden distron maskepp van egy kicsit, es a legtobb upstream pedig nem koveti mindet, illetve probal olyat csinalni, ami portabilisabb. Upstream tobbnyire distrora bizza, a distro maintainerek meg sajat szajuk ize szerint csinaljak, igy ket distro kozott az init script elegge mas tud lenni.

Maximum azért, mert az adott disztró összeállítója nem csinálta meg egy közös eljáráskönyvtárban, vagy ha megcsinálta, az adott initscript elkövetője nem használja azt.

Welcome to real life.

Sőt, a scriptek futtatása nem szól arról, hogy valamit életben kell tartani, ha kidől - erre az inittab való.

Az inittab az egy formedveny, egyreszt. Masreszt ha ez igy lenne, akkor nem szolt volna jopar cikk tiz evvel ezelott is olyan megoldasokrol, amik eletben tartottak a kulonbozo serviceket (pl daemontools).

Mondok egy peldat! Vegyuk a syslog-ng -t, ami ugye egy loggolo alkalmazas, es kene neki halozat, hogy tudjon a kozpontba kuldeni logokat. Tehat belerakok az init scriptbe egy Required-Start: $network sort. Igy a sysvinitre epulo dependencia kezelo rendszer be tudja kotni a megfelelo helyre. Ez eddig jo. Amde ezen kivul meg kell pidfile kezeles, es jo lenne, ha nem indulnank el ketszer - ennek kezelese nemileg races, bar az utobbi idoben sikerult egesz korrektul megcsinalni, es nem hasal el (lasd Debianon /etc/init.d/syslog-ng syslog_ng_wait() fuggvenyet). Ezen kivul ott van ugye a start-stop-daemon hivas, ami szinten megnezi, el-e meg masik syslog-ng, a biztonsag kedveert. Ez az egesz azert elegge torekeny. Arrol nem is beszelve, hogy systemd nelkul egy regebbi Linuxot vagy egy haklisabb OS-t siman be lehet akasztani boot kozben azzal, hogy rengeteget logol az ember /dev/log -ra, mert a syslogd keson indul, es a /dev/log betelik, es blokkol a syslog() (workaroundoltunk mar ilyen hibat anno!).

Ezzel szemben a systemd unit file 15 soros, ko egyszeru, es a systemd megoldja az osszes problemat, messze jobban, mint a sysvinit. Azert, mert a sysvinit nem tudja, mert buta, es nincs meg neki annyi informacio, mint a systemdnel. A systemd latja az egesz rendszert, az osszefuggeseket, az osszes processt es unitot egyszerre, es ezek alapjan sokkal hatekonyabban tud segiteni nekem. A sysvinittel ezt nem lehet megcsinalni, legfeljebb imitalni, ami elobb-utobb el fog torni.

Es igen, a sysvinit nem arrol szol, hogy mi mitol fugg. Es ez baj. Lehet, hogy 20 eve nem volt problema, de ma, amikor lenyegesen komplexebb rendszereket epit az ember, szeretne azt egyszerubben es megbizhatobban csinalni. A sysvinittel ez eselytelen.

--
|8]

Igen, ha neked van rá szükséged, akkor ne várd az dadusnénitől, hogy kitalálja és megnézze, hogy minden megvan-e. Felnőtt, önálló(!) ember vagy. Mint ahogy egy szolgáltatásnak is önállóan el kell tudnia dönteni, hogy el tud-e indulni, vagy sem.

Tudhatja a sysvinit is ezt, nem túl bonyolultan, de akár lehetne a sysvinit-tel együtt élni képes, meglévő eszközt is használni, ha például függőségek kezelésére van ingerenciád.

A Linux-on meg egészen másképp lesz ezek után, mint a többi Unix, vagy Unix-szerű rendszeren... Ugyanis létre lett hozva egy Linux-only megoldás...

Az inittab jól használható, csak ismerni kell, hogy mire való, mire jó, és mire nem jó. Olyan service-t respawn-olni, ami pl. tetszőlegesen rövid idő után is elhasalhat, olyat nem szabad, mert ki fogja hajítani az init (respawn too fast). A daemontools ezt (is) megoldotta, illetve azt, hogy kényelmesen lehessen a kezelt (életben tartandó) szolgáltatásokat indítani/leállítani.

A logolásról írtban szerintem van egy logikai hiba: A hálózattól nem szabad függenie, hiszen hálózat nélkül is kell logolni. Ha nincs hálózat, oldja meg, hogy helyben bufferel/etc, de ne fogja meg a rendszert. Ha viszont az a cél, hogyt csak működő központi logolás mellett éledjen fel a gép, akkor ne csodálkozz, hogy kihúzott utp-kábellel nem indul el rendesen :-P

Igen, ha neked van rá szükséged, akkor ne várd az dadusnénitől, hogy kitalálja és megnézze, hogy minden megvan-e. Felnőtt, önálló(!) ember vagy. Mint ahogy egy szolgáltatásnak is önállóan el kell tudnia dönteni, hogy el tud-e indulni, vagy sem.

De, 2014-ben elvarom, hogy a programok dolgozzanak ertem, es ne forditva. En sem mindent magam csinalok, hanem mas emberekre, az o munkajukra tamaszkodom. Nem javitok mosogepet, nem nyulkalok elektromos vezetekhez, mert van aki megcsinalja ezt helyettem. Pedig szuksegem van mind mosogepre, mind elektromossagra. De nem fogom tudni soha "kidebugolni", miert romlott el a mosogepem. (Igen, sarkitas kicsit, ez van.)

Tudhatja a sysvinit is ezt, nem túl bonyolultan, de akár lehetne a sysvinit-tel együtt élni képes, meglévő eszközt is használni, ha például függőségek kezelésére van ingerenciád.

Igen. Linuxon ez evek ota igy van, ezert vannak a Required-$foo: headerek az LSB init scriptekben. De ez egy elegge torekeny megoldas, mert a sysvinit buta, es nem ad eleg informaciot ahhoz, hogy tenyleg hatekony es korrekt megoldast lehessen ra epiteni.

A Linux-on meg egészen másképp lesz ezek után, mint a többi Unix, vagy Unix-szerű rendszeren... Ugyanis létre lett hozva egy Linux-only megoldás...

Nem akarlak elkeseriteni, de Linuxon mar egy jo ideje mas a rendszer. A dependency based parallell boot (Debianon 2010 majus ota default) legjobb tudomasom szerint linux-only. BSD-ken szinten tok maskepp mukodik az init, bar vannak hasonlosagai. Solaris SMF, es a tobbi UNIX amihez volt szerencsem, mind-mind egy kicsit mas volt.

A Linux-only megoldas mar joideje letezik, es hasznaljuk.

Az inittab jól használható, csak ismerni kell, hogy mire való, mire jó, és mire nem jó.

Igen. Amire egy modern rendszerben szukseg van, arra peldaul nem jo, mert nincs meg nala elegendo informacio.

Peldaul a resource kezeles, privat halozat/fs namespace kezeles, cgtop es hasonlo megoldasokat sysvinitre epiteni szep kihivas lenne. Marpedig ezekre egy olyan kornyezetben, ahol jopar containert futtat az ember, igencsak szukseg van. Meg lehet oldani barkacsolt scriptekkel, de az nem lesz se kenyelmes, se hordozhato, se standard.

--
|8]

Igen, a programok dolgozzanak. Ha elindítom, nézzen körül, hogy minden rendben van-e, és ha nem, akkor szóljon, hogy x, y, meg z feltétel hiányában nem tudok futni. Legyen önálló.
Az információk 99%-a kinyerhető most is a rendszerből, ezeket kell kinyerni, és a sysvinit-et használó indítóscripteknek a rendelkezésére bocsátani, hogy tudják azokat egységes módon használni. És ezeknek az infóknak a használatára meg fel kell készíteni a scripteket, ami szintén nem egy rettenet nagy rakétatechnológia - ha a "mit tudjon" agyalásban nem akarunk túl nagyot álmodni.
Igen, lehet házibarkácsolni, ami - a Linux-only systemd-hez hasonlóan - sem nem portábilis, sem nem standard megoldás.

Legyen onallo kis halalcsillag mind, mi? :) Jo lesz az, nem lesz bonyolult! Nagyon konnyu lesz kiboviteni, ha X osszefuggo service ele be kell tenni egy ujat! Csak fel tucat helyen kell belenyulni! Tenyleg fasza elkepzeles.

Egy systemctl status-t peldaul annyira egyszeru lenne sysvinitbe is beletenni! (Lehet mondani, hogy ez felesleges, meg kinyered logbol - de sokkal praktikusabb, ha ezt egy program megcsinalja neked.)

Igen, lehet házibarkácsolni, ami - a Linux-only systemd-hez hasonlóan - sem nem portábilis, sem nem standard megoldás.

FYI, sysvinit se nem portabilis, se nem standard, legfeljebb a neve, es a mukodese odaig, hogy inittab. Ami azon felul van, az nagyon eltero tud lenni. Maskepp nez ki egy BSD-s init script, mint egy HPUXos, vagy Linuxos.

--
|8]

akkor valamit lehet, hogy en nem ertek? azt allitottad, hogy a systemd szepen ellenoriz mindent, persze csak azt amit megmondasz neki.
igy szepen irogatod a configot, hogy melyik interface/akarmi kell hogy keszen legyen mire indul a bind. ez ugyanaz mint amikor az init-scriptbe irogatod. tehat nem akkora vilagmegvalto dolog ez a systemd-ben.
raadasul azert a bind (tetszoleges alkalmazasra cserelheto) iroi eleg batrak (vagy eppen tudatlanok) lennenek, ha majd arra hagyatkoznanak amit a systemd/smf/sysvinit/akarmi mond. vagyis meg csak nem is mondja, hanem egy akarmilyen, akarki altal modositott/modosithato systemd-config/sysvinit-script allitja, hogy minden rendben azzal, hogy elinditja? azert megiscsak vannak a bind-ben nemi ellenorzesek az indulasnal en ugy tudom. pl. bindeles, log-file megnyitas sikeressegenek ellenorzese es a tobbi.
mivel ezeket ugyis megcsinalja az adott alkalmazas, ezert kulon jo, hogy elotte lefut meg egyszer ugyanez. csak hogy gyorsan tudjanak indulni a service-ok...

ok, ez egy eroteljes sarkitas. azert remelem ertheto volt, hogy mit gondolok errol a mindent a systemd-nek kell csinalnia dologrol.
azzal egyetertek, ha egysegesitik az init-rendszert, raferne. csak az irany nem tetszik.

Elbeszélünk egymás mellett. Ez a thread a 1793410 körül ment el egy teljesen utópisztikus világba, ahol zeller azt írta, hogy "egy szolgáltatásnak is önállóan el kell tudnia dönteni, hogy el tud-e indulni, vagy sem" - én erre reagáltam.

A BIND-nak kezelnie kell a hibákat, de nem kell törődni a függőségekkel, azzal törődik a systemd.

A sysvinit-tel meg lett oldva a sorrendiség, de ezt túlzás függőség-kezelésnek nevezni, mert se hibakezelés se az ondemand igények kielégítése nincs benne, csak egy kényszer szülte hack.

lehet hogy nemileg mellekvaganyon jarok, de szeretnem meg kicsit folytatni.
mi szamit hibanak amit az alkalmazasnak kell kezelnie es mi fuggosegnek amit a systemd oldana meg? pl. az, hogy letezik a /var/log/bind konyvtar melyik kategoria? es ki donti el, hogy melyik mi? a systemd vagy a tetszoleges alkalmazas esetleg?

Hát, nem igazán gondolkoztam még ilyen kérdéseken, de elemezzük. Legyen 2 csoport:
1. statikus függőségek: library-k, mappák, jogosultságok - minden ami a fájlrendszeren van tárolva. Ezeket a függőségeket a csomagkezelő jól kezeli.
2. dinamikus függőségek: service-ek, hálózati setup, mountok, belépett juzerek, stb - a futó rendszer állapota. Ennek egy részét kezelte a sysvinit a sorrendiséggel, de közel se átfogóan vagy hibatűrően.

Az alkalmazásnak minden hibát kezelnie kell. Gond, hogy az alkalmazás nem tud minden hibát észlelni, mert nincs átfogó képe a rendszerről. Pl nem tudhatja, hogy nem szabad kommunikálni egy adott IP címmel - azt csak a lokális tűzfal tudja.

Nem tudom mire akarsz ezzel kilyukadni, de már érdekel. :)

arrafele probalok haladni, hogy az alkalmazas egyebkent is lekezeli a hibakat/fuggosegeket. attol most talan tekintsunk el, hogy jobban-rosszabul oldjak meg az alkalmazasok ezt. az init-rendszernek, ide ertem a systemd configjat es a sysvinit scriptjeit is, csak a nagyon alap dolgokat kell mindenkeppen ellenorizni. az hogy az adott port-ra lehet-e bindelni, egyaltalan nem az init/systemd/akarmi gondja. szinten nem az init gondja az alkalmazas logolasaval foglalkozni, hogy eppen hogyan kozli veled oldja meg az alkalmazas: stderr, logfile stb.

az alkalmazasnak nem kell atfogo kepet kapnia. futnia kell, ahogy a program iroi megalmodtak. ehhez szuksegesek/vannak jogai amikkel el tudja donteni, hogy fog-e tudni futni rendesen ill. detektalja a hibakat. (a tuzfal nagyton rossz pelda: annak eppenhogy minden alkalmazastol/service-tol fuggetlenul is kell tudnia mukodni)

eleg nagy problema, ha az init-rendszerre tamaszkodik egy alkalmazas. van esetleg a systemd-nek valamilyen interface-e amin az alkalmazas le tudja kerdezni pl. a halozat allapotat? ha nincs, akkor az alkalmazasnak maganak kell kideritenie, hogy tud-e bindelni az adott interface adott portjara. (leragadtam ennel a port-kerdesnel, de jobb pelda hirtelen nem jut eszembe.)

sorrendiseg vs. fuggoseg. ugy latom mashol is eleg sokat veszik elo ezt az ervet a systemd mellett. az en szempontombol teljesen mindegy a ketto. pl.: 3 service, egymasra epulnek, fuggoseg van. fuggoseg-kezelessel: az 1. fut, a 2. nem indul hiba miatt, igy a 3. sem fog. sorrendnel: a fentiek miatt a service-ok ugysem fognak elindulni ha a fuggoseguk nem indult el elobb, mert ellenorzik a blablabla... nem igazan jon ki a kulonbseg. raadasul meg mukodik is mint latjuk.

> az alkalmazasnak [...] futnia kell, ahogy a program iroi megalmodtak
Szerintem ez nem így van, adott környezetben kell futnia, amiről a megálmodóinak fogalma sincs vagy tán el sem tudták képzelni, hogy ilyen környezetben kell majd működnie a szoftverüknek. A jó szoftvernek úgy kell működnie -a képességeihez mérten- ahogy elvárom, nem ahogy a fejlesztője elképzelte.

> az hogy az adott port-ra lehet-e bindelni, egyaltalan nem az init/systemd/akarmi gondja
Adott esetben ip:port párosra bindelsz, mert mondjuk 2 IP címe van a gépnek. Kinek a gondja, hogy az IP cím fel van-e húzva? Ha ugyanis nincs, az valszeg egy fatális hiba lesz az alkalmazásnak. Hogy tudja ezt megoldani önmagában?

> a tuzfal nagyton rossz pelda: annak eppenhogy minden alkalmazastol/service-tol fuggetlenul is kell tudnia mukodni
Fordítva viszont nem feltétlenül igaz. Induljon el az alkalmazás akkor is, ha nem sikerült betölteni a tűzfalat, az IPS-t, az IPSec policy-t, a VPN-t, stb? Biztos ez a jó megoldás mindenhol? Honnan tudja az alkalmazás, hogy ezek betöltődtek és működnek?

> van esetleg a systemd-nek valamilyen interface-e amin az alkalmazas le tudja kerdezni pl. a halozat allapotat?
Azt ne akarja tudni az alkalmazás, csak csinálja a dolgát.

A sorrendiséggel pl probléma lehet, hogy nem kezeli a hibákat*. Ha nem töltődött be valami akkor spongyát rá, jöhet a következő, az hátha - ami aztán emiatt talán rosszul működik majd. Nem biztos, hogy nem indul el, lehet elindul és ezzel nagyobb kárt csinál.

* persze ez is implementációfüggő

> az en szempontombol teljesen mindegy [...]
Neked ez után is teljesen mindegy lesz, ugyanúgy bebootol a géped mint eddig. Sokan vannak azonban akik tényleg szopnak a sysvinit-tel.

> A jó szoftvernek úgy kell m\u0171ködnie -a képességeihez mérten- ahogy elvárom, nem ahogy a fejleszt\u0151je elképzelte.
hat ez a legritkabb esetben szokott osszejonni :) inkabb az alkoto elkepzelesei ervenyesulnek. a kornyezetet pedig a programnak kell felterkepeznie mindenkeppen es eldontenie, hogy itt tud e mukodni. pl. interface/ip hianya.

megprobalom osszefoglalni, hogy mi is a problemam: az alkalmazas altal elvart kornyezet egy reszet az init tudja ellenorizni, de kozel sem mindent. ez mar csak az elofordulo alkalmazasok szamossaga es azok kulonbozo elvarasai miatt sem johet ossze. adott a kerdes, hogy meddig ellenorizzen/ellenorizhet az init? es ez az egyik pont ahol szerintem 'kicsit' elszalltak a systemd alkotoi es/vagy tervezoi. tul sok mindent beletettek, aminek szerintem kozel sincs ott a helye ill. elvarhato hogy az alkalmazas ellenorizze ezeket. pl. sok koze nincs az init-nek ahhoz, hogy melyik alkalmazas hol tarolja a logjat es mit ir bele. user-eket meg foleg ne akarjon mar beleptetni.
mindazonaltal jo otletek is vannak a systemd-ben: cgroups, resource-limits stb. de azzal hogy tul sok mindent probal csinalni ezeket az elonyoket jelentosen csokkenti. en szemely szerint meg biztosan varok 1 evet a valtassal, hatha lesz elmozdulas valami kevesbe osszetett dolog iranyaba. az osszetettseggel nincs bajom, csak ha ezt a rendszer alapveto komponenseben latom. ezen kozben itt a sysvinit peldaja, hogy lehet egyszerubben is csinalni ezeket. igen, hianyoznak kepessegek amiket a systemd ad, de milyen aron? ez egy lehetseges fejlodesi vonal, majd kiderul, hogy mennyire vallalhato. mivel tobb jelentos linux disztribucio ezt valasztotta, biztosan fogom/fogjak elesben is hasznalni. ott ki fog derulni ha ez az ut nem jarhato.

A szoftverek szerencsére nem így működnek; nem kezdik el feltérképezni a környezetüket, ők csak teszik a saját kis dolgukat amíg hibába nem ütköznek.

> itt a sysvinit peldaja, hogy lehet egyszerubben is csinalni ezeket. igen, hianyoznak kepessegek amiket a systemd ad, de milyen aron?
Ez a lényeg: túl nagy áron. Olyan áron, hogy többet topogunk jobbra-balra mint amennyit előrelépünk. Ez a magas ár hívta életre a systemd-t.

nem ertetted meg a hozzaszolasomat, kicsit modositok:

itt a sysvinit peldaja, hogy lehet egyszerubben is csinalni ezeket. igen, hianyoznak kepessegek amiket a systemd ad, de milyen aron adja a systemd ezeket?

nem tudom milyen szoftverekkel talalkoztal eddig, de alkalmazas indulaskor altalaban ellenorzi, hogy a mukodes feltetelei megvannak-e: log-file-t tud-e nyitni, portra bindelni, config-file letezik-e, esetleg mar fut egy peldanyban stb. en meg olyan alkalmazassal nem talalkoztam, ami ne vegzett volna indulaskor valamilyen ellenorzes(eke)t. (legfeljebb ha en irtam, de most nem ilyen kategoriaju alkalmazasokra gondolok).

Alapvető fogalmi zavarban vagy.

> alkalmazas indulaskor altalaban ellenorzi, hogy a mukodes feltetelei megvannak-e
Ez egyszerű hibakezelés, nem a működés feltételeinek ellenőrzése.

A működés feltétele pl az, hogy megfelelő-e a runlevel, van-e mountolva a szükséges adat, stb. Ezeket mikor ellenőrzi pl a BIND?

hat ha neked hibakezeles az, ha a mukodes felteleit nem talalja megfelelonek es kilep, mert nincs mountolva a /var/log akkor az.
ettol meg az eredmenye ugyanaz lesz: nem fog futni az adott alkalmazas. esetleg nem vart mukodest fog mutatni, mert valamilyen feltetel hianyzik? ez kb. 2^24 kulonbozo esetben fordulhat elo. a systemd mindegyik esetet tudja kezelni? nyilvan nem. ha pedig csak a gyakori esetekre szukitjuk mint mount, interface-ek stb. akkor nem igazan jutunk el az idealis allapotba, mert kell(ene) az az ellenorzes hibakezeles.

en alapveto programtervezesi hibanak tartom azt ha nincs ellenorzes (nevezhetjuk hibakezelesnek vagy akar kivetelkezelesnek is), hanem az indito kornyezetre (init) van bizva az ellenorzes, hogy indulhat-e az alkalmazas. te mintha azt allitanad, hogy ilyesmivel nem kell foglalkoznia az alkalmazasnak majd a systemd (vagy akarmi) megoldja. jol ertettem?

Szerintem te sem vagy épp naprakész értelmezésben.

Megfelelő-e a runlevel?
A runlevele egy, a *rendszergazda* által kiválasztott/beállítot érték. Az hogy gyártók, terjesztők szeretnek valamiféle *nekik* szimpatiklus logikát beleerőltetni, az egy dolog. A bind (ha már ő volt a példa), röhögve fut a runlevel fogalmat nem ismerő OS-eken (ugye, BSD) - azaz neki nem dolga azt ellenőrizni (főleg, hogy tőle teljesen független valami). Sőt, ha valakinek kedve van, bármikor átkonfigurálhatja úgy a rendszerét, hogy a runlevel-ek egymástól teljesen független állapotnak látszódjanak (merthogy azok), nem pedig ilyen "fölfele haladok több minden lesz, lefele megyek, kevesebb minden lesz" - ahogy jelenleg kb mindenki konfigurálja.

Van-e mountolva szükséges adat?
Ez már önmagában rossz megfogalmaás, de e fölött átsiklunk. Milyen mountolást kéne a bind-nak lekérdezni? A / meglétét? A /var meglétét? A chrootolt /var/spool/bind meglétét? Nem. (Ugye pl. linux terjesztések hülye szokása, hogy össz vissz 2 FS van, a root meg a boot.) A bind feladat max annyi, hogy azt ellenőrizze, hogy a szükséges vackai elérhetők-e.

De hajlandó vagyok az ellenvéleményeket meghallgatni és mérlegelni őket. Ezek itt fent nem azok.

Pontosan erről beszélek én is, de mindegy, ennek a szálnak semmi értelme az elejétől fogva. Eddig se sok türelmem volt hozzá, ezért is az összecsapott válaszok, mert ez a megközelítés nem vezet el sehova.

Nem is igazán tudom megragadni ezt a hozzáállást, hogy fölösleges a függőség-kezelés az init rendszerbe, döntse el minden alkalmazás maga, hogy akar-e futni úgy ahogy a programozója megálmodta. Ez számomra nonszensz, fogalmam sincs hogy nézne ki egy ilyen rendszer.

Szóval részemről off.

szoval sysvinit - nincs fuggosegkezeles. fuj
systemd - van fuggosegkezeles, jo.

igy is lehet ertelmezni. de reszemrol nem is arrol van szo hogy vitatnam a fuggosegkezeles hasznalhatosagat. amivel problemam van azt feljebb leirtam.
a systemd nagyszeru feature-jei nelkul eddig is volt linux, systemd elott is volt elet. lehet, hogy nem volt tokeletes, viszont bizonyitottan mukodik.

Ha pl. a kérdés, hogy a log mount létezik-e (mert pl. egy NFS-en van), akkor ez annyi, hogy felveszed a var-log.mount -ot függőségként.

Az alkalmazásnak minden hibát kezelnie kell, viszont a rendszernek nem lenne szabad próbálkoznia az alkalmazás elindításával, ha az GARANTÁLTAN nem fog tudni elindulni (mert pl. egy mount hiányzik, még nincs hálózat etc.)

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

Elméletileg lehetnének a következő targetek:

- network --> ha elindult, akkor tudod, hogy van hálózat, mindenestől
- eth24 --> ha elindult, akkor tudod, hogy van eth24
- bind --> ha elindult, akkor tudod, hogy van névszervered

Elméletileg megteheted, hogy a bind indítását az eth24 sikeres elindításától teszed függővé. De ebben az esetben ha át akarsz költözni az eth77-re, akkor azt a bind konfigjában és a bind függőségeinél (2 db helyen) is meg kell mondanod. Ennél célszerűbb, ha az általánosabb "van net!" fogalomtól teszed függővé a bind indítását, az nem változik gyakran, mivel eldöntendő kérdésre válsz, nem pedig kiegészítendőre.

( uid_194 | 2014. 10. 20., h – 11:21 )

Ha a veteranok egy csoportja fork helyett fogna, es a hianyzo kodot megirna, akkor nem kene ennyit nyignia senkinek. De forkolni es egy egesz distrot karban tartani biztosan konnyebb.

--
|8]

Nem igazán hiányzó kódokról van szó. A többség elsődleges gondja az, hogy túl sok mindent akar csinálni a systemd. Ráadásul e miatt túl sok függése van más rendszerek irányába, amivel az egész OS-t bevasalja (rengeteg komponenst nehéz vagy lehetetlen mellette lecserélni).

Egyébként másnak is eszébe jutott a kód alapú megoldás: http://uselessd.darknedgy.net/

Igazából az egész vita arról szól, hogy a nagy integráció miatt (GNOME függ a systemd-től, systemd függ az udevtől meg még rengeteg más dologtól) kezd megszűnni a régi hackelgetős, módosítgatós kialakítás, és helyette egy felnőtt, monolitikus, szabványos kiépítés kezd megvalósulni (a windowshoz vagy a macosxhez hasonlóan). Ez a változás - noha sokaknak hasznos - másoknak nem jön be.

Zavard össze a világot: mosolyogj hétfőn.

De, hianyzo (tobbnyire upstream) kodrol van szo. Arrol van szo, hogy ha ezek a forkolos emberek a nyigas helyett megoldanak, hogy pl a GNOME (es meg 1-2 dolog ami nekik oly fontos) menjen systemd/logind nelkul, akkor meg lenne oldva a problema. De a munka budos. Ennyirol van szo.

Ertem en, hogy a systemd egyeseknek nem tetszik, es ezzel az eg vilagon semmi baj nincsen. De a fork oka nem ez. A fork oka az, hogy Debianon belul se ingerencia, se eroforras nincs arra, hogy az alternativ init rendszereket ugyanolyan modon tamogassuk. Es erre nyilvan a fork a megoldas, nem pedig a segitseg.

A systemdhez vajmi keves koze van ennek az egesz ugynek, az csak egy urugy. Rengeteg hasonlo dolog tortent debianban, amikor a usereknek nem volt valasztasuk, megis valtas tortent: glibc -> eglibc, gnome2->gnome3, kde3->kde4, es meg lehetne sorolni.

--
|8]

Azok, akik amellett voksolnak, hogy legyen szabadon választható az init megoldás, egy cseppet sem veszik figyelembe azt, hogy onnantól fogva minden egyes service-t tartalmazó csomagnak szállítania kellene minimum kétféle (de ha valakinek upstart a kedvence akkor már háromféle) job indító metódust. Debianos csomagkarbantartók (amellett hogy max respect nekik) arra sem voltak képesek, hogy egységesen átálljon minden általuk kiadott csomag upstart-ra. És még azt várnák el, hogy ezen túl mégtöbb fajta init rendszer legyen?! És most még csak és kizárólag a szolgáltatások indítóiról beszéltem, a rendszer által használt unit-ok még szóba sem kerültek (mint pl. mountall, networking, tty*, dbus, console stb.).

Nagyon jó programozók is követnek el apró hibákat, aminek aztán súlyos incidens lehet a vége. Én egyáltalán nem láttam még olyat, hogy egy ilyen hiba miatt bárkit kirúgtak volna bárhonnan.

Egyébként nem csak az ő sara a dolog, próbált segítséget kérni mielőtt lépett.

Akkor emlitenem meg mondjuk a kernelt is. Az is valtozik debian releaserol debian releasere, sokszor eleg sok dolgot eltorve. Az elegge a rendszer kritikus resze :)

De volt itt libc5->libc6 valtas is, c++ ABI kavaras, ffmpeg->libav (es lehet, hogy majd libav->ffmpeg, bar ez sem kritikus resz, kiveve ha desktop user vagy), stb.

Attol, hogy valtozik, es kritikus komponens, a valtas meg nem lesz eredendoen rossz es meggondolatlan.

--
|8]

( manfreed (nem ellenőrzött) | 2014. 10. 20., h – 13:15 )

Az upstarttól miért irtózik mindenki? Mit gondoltok róla?

Nem nagyon akarok flame-et kelteni, de a fentiekből azt olvasom ki, hogy a systemd overkill, a sysvinit pedig elvénült. Mi baj a harmadikkal, leszámítva hogy azt Ubuntuék csinálják, amit sokan nem szeretnek?

( uid_16313 | 2014. 10. 20., h – 14:43 )

Sosem értettem, hogy egy sokat bizonyított rendszert miért is kell megváltoztatni?

--
robyboy

"Gondolkozni nehéz, ezért legtöbben ítélnek." - Márai Sándor

( uid_4656 v | 2014. 10. 20., h – 17:42 )

Hmm, az oldalból jól látszik, hogy inkább veterán unix adminokról van szó, és nem webdizájn szakemberekről :-D

( asch v | 2014. 10. 20., h – 18:32 )

A munkájukat féltik, mert innentől egy hátulgombolós gimnazista is karban fog tudni tartani egy 10000 virtualizált gépből álló HA clustert 2 soros konfigfájllal.

Annak a 69 binárisnak egészen más a tervezett funkcionalitása, mint az egy szál /sbin/init binárisnak (meg a /etc/inittab -ból elinduló scriptnek, ami végigyalogol a megfelelő scripteken és leállít/inidít, amit az adott futási szinten kell). Ha a monolitikus-t szó szerint értelmezzük, akkor nem az, ha az egyes jól körülhatárolható funkciókat megvalósító komponensek önállóságát, cserélhetőségét nézzük, akkor bizony eléggé zárt és megbonthatatlan motyó.
Oké, fordítási időben kapcsolókkal megadható, hogy mi forduljon, és mi nem. Ezt lehet modulárisnak is hívni, de a kimaradó modulokat mivel lehet helyettesíteni?
Ami leginkább tetszik: "Porting systemd to other kernel is not feasible. We just use too many Linux-specific interfaces." - szóval az, aki nem csak Linux-ban gondolkodik (akár fejlesztő, akár admin), a más rendszerekben lévő initet is, meg a Linuxos systemd-t is kell támogatnia, ha több platformon működő motyót akar írni, és az valamilyen, szokásosan initscriptből indított szolgáltatást valósít meg.

Ez egy értelmetlen cél. Kb. mint a viccben a szovjet borotválógép esete: ha az emberek mind egyformák lennének, akkor lenne létjogosultsága. Mivel nem egyformák, ez nagyjából kizárt dolog, hogy elérhető legyen (és ha még össze is jönne, az meg önmagában baj lenne).

A kulonbseg az annyi, hogy a systemdt teljesen jol lehet debugolni, minden komponenset. Ez jol dokumentalt is. A sysvinit az minden, csak nem jol dokumentalt. Ha ott valami szetesik, akkor ha szerencsed van es lattal mar hasonlot, akkor ugyan megtalalod pikk-pakk (ahogy systemdnel is), de ha valami furcsabb van, akkor kezzel kell vegigszivni az egeszet. A systemd eseteben erre vannak sokkal jobb eszkozok a set -x -nel. Eszkozok, amik segitenek. Az ember meg tobbnyire eszkozhasznalo leny, a jo rendszergazda meg lusta, es utalja a felesleges munkat. :P

--
|8]

Azért a "nem jól dokumentált"-tal vitatkoznék, de sebaj. Elég sok Unix-ban ott figyel (és ott is fog, mert ne felejtsük el, hogy a systemd erősen kötődik a Linux-kernelhez, úgyhogy a portolhatósága konvergál a nullához), és a Linux-tól eltérően máshol szokás alaposan dokumentálni.

Milyen "furcsább van?"-ra gondolsz? Mi lehet "furcsább" abban, hogy egy script mit csinál, mit nem csinál? EL kell tudni olvasni... Ja, és a "láttál már hasonlót" ra csak annyit, hogy sysvinit-es mókánál azért ~40 év, meg picivel több telepített sysvinit példány okán szerinted mennyivel van több esélyed arra, hogy "valaki már látott olyat", mint egy Linux-only motyónál?

A sysvinit dokumentacioja kimerul par man oldalban, es pont az /etc/init.d/rc, ami a runleveleket implementalja, az - Debianon legalabbis - nem rendelkezik dokumentacioval, raadasul ranezesre elegge Debian-only. Innentol pl RedHaten szinte biztos mas lesz, valoszinuleg hasonlokepp jol dokumentalva.

Furcsabb: peldanak okaert a gep neha felbootol, neha nem. Logod nincsen, mert syslogd meg nem indult el. Talald ki, melyik script, es miert hasal el, is miert csak neha. Feltetelezve, hogy Debian-hoz hasonlo, dependenciakat kezelo sysvinit szornyrol van szo. (Jelzem, az ilyen dependenciak kozel sincsenek 40 evesek, tobbnyire linux-only megoldas ez, es jopar felekeppen megoldottak.)

Meg lehet oldani, persze, kello gyakorlattal nem is akkora kihivas. Cserebe egy olyan rendszerrel, ahol a debugolasi lehetoseg a set -x -nel es a more-nal nemileg szofisztikaltabb, nagysagrendekkel egyszerubb lesz.

--
|8]

Nem csak debilelinux létezik, sőt... A felbootol/nem bootol esetben értelmes rendszeren lehet látni, hogy hol, melyik szolgáltatásnál akadt el a dolog (nekem pl. első dolgom kikapcsolni az indítóscriptek futását eltakaró baromságok kikapcsolása - a konzol a boot során nem azért van, hogy bámuljam az xyz disztró logóját, meg alul viháncoljon a bitkolbász), onnan el lehet indulni, akár Single módban bootolva, akár interaktívan (RHEL) kiválasztva, hogy mi inuljon el, és mi nem. Egyébként ilyen gondom volt/van az rsyslog5-tel, mert annak az initscriptje is olyan, hogy feltételez mindenfélét az induláskor, és semmit nem ellenőriz, de megoldottam. Semmilyen egyéb eszköz nem kellett hozzá, mint a scripteket elolvasni, megérteni, hogy mit és miért akar csinálni (rosszul), és hogyan lehet azt kijavítani. Igen, kell hozzá némi gyakorlat, de aki ezt nem tudja, az menjen kapálni, de ne akarjon komolyan üzemeltetni.

Egyébként a sysvinit-hez nem igazán kell sok kilométernyi doksi, mert mint írtam, alapvetően egyszerű, hiszen a KISS elvet szem előtt tartva készült.

Hat, ha neked a set -x es a more a jeghegy csucsa, akkor legyel boldog vele. En szeretem, ha az eszkozeim segitenek nekem. A rendszer van ertem, szolgaljon ki, segitsen. Ne nekem kelljen minden baromsagot megcsinalnom, amit egy program hatekonyabban tud nalam.

Egyébként a sysvinit-hez nem igazán kell sok kilométernyi doksi, mert mint írtam, alapvetően egyszerű, hiszen a KISS elvet szem előtt tartva készült.

Ebbol a stupid sikerult. Tobbszaz sornyi shell script kaosz, ami rendszerrol rendszerre valtozik minden, csak nem simple.

--
|8]

És így születnek azok a scriptek, amik vagy egy esetleges update után újrakalapálást igényelnek kézimunkával (szerencsés esetben a csomagkezelő készít backupot róla, pech, ha felülírja), vagy ha a csomagkezelő békénhagyja, akkor meg időtlen időkig ottragadnak még a dist-upgrade-k között is, és misztikus hibákat generálnak az időközben megváltozott környezetben. Amit persze egy olvasni tudó élből hárít - miután rájött, hogy honnan ered a hiba. Ez tényleg a tökéletes, kényelmes, és nemutolsósorban hatékony megoldás...

És a frissítés a systemd-s saját beállításokat/módosításokat változatlanul hagyja? Vagy felajánlja, hogy nézd meg a különbségeket, vagy csinál automatikusan összefésülést? Vagy hogyan kezeli az egyedileg kreált beállításokat? Nem neked, mint üzemeltetőnek, hanem a csomag előállítójának kellene az initscriptet rendesen megcsinálnia (úgy, hogy az adott verzióhoz passzolva önállóan el tudja dönteni, hogy indítható-e az adott szolgáltatás (mert valamennyi feltétele adott), vagy sem.
Hirtelen ötletkéne draft draftja: egy konfigurációs állomány, amiben file|dir|interface|hostaccess|mount|service cimkékkel felsorolod, hogy mire van szükség, és azt egy egységes script megnézi, hogy megvannak-e. Ezt a scriptet meghívja az initscript, és ha sikeresen lefut, akkor mehet a móka, ha nem, akkor nem.

Változatlanul hagyja, mivel erre is gondolva tervezték: /var/lib/systemd alatt a csomagból érkező unit fájlok, /etc/systemd alatt a saját unit fájlok és az override-olandó unit-ok (pl. /etc/systemd/system/named.service.d/10-foo.conf). Utóbbiakat a csomag nem bántja, azokat illik/kell használni.

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

Ahogy egy apt-get update is szól, ha eltérést talál, és rákérdez, hogy megtartsa/lecserélje/diff-et mutassa. Igaz, ezt csak akkor, ha konfigurációs állományként van jelölve az adott fájl.
Az, hogy a systemd hasonlóan csinálja, az nem véletlen - logikusan átgondolva ennyire van szüksé a függőségek/futási feltételek figyelése terén. Az, hogy szofisztikáltabb (gondolom, "menet közben" rajta tartja a szemét a feltételhalmazon, illetve a futó szolgáltatásokon), az talán abból adódik, hogy amit írtam, az nagyjából annyi idő alatt született ötlet, amíg leírtam.

( NevemTeve | 2014. 10. 20., h – 20:53 )

Ugye nagyon ciki, hogy nekem már a Debian mostani rendszere is túl fejlett(*), nemhogy előre szeretnék lépni, inkább visszafelé, olyan Slackware-es iránya...

(*): scriptek végtelen káoszban hívják egymást összevissza, alig találom meg az effektív információt (még az furcsa, hogy XML nincs belekeverve a mesébe (kivéve, ha már van, csak nem láttam))

( Salcay v | 2014. 10. 20., h – 23:17 )

Felfújjátok ezt az egészet, pedig baromi egyszerű! Valakinek a tudása, tapasztalata, és céljai olyanok, hogy a sysvinit felel meg neki, másnak meg olyan, hogy a systemd. Maradjon meg a választás lehetősége! Ennyi a nagy kérés!

Az, hogy valaki átlátja a script dzsungelt, az jó. Igen, át lehet látni, disztrók közt is, és ki is lehet irtani. Nem kötelező a gyakornokok által összekalapált vackokat használni. Épp erről szól ez az úgynevezett "unix filozófia". Megvan a lehetőség a választásra! Csinálhatod másképpen, és nem kell azon az úton maradnod, amit a fejlesztők megálmodtak! Gyakorlatilag mindegyikőtöknek épp úgy adott a lehetőség, hogy saját init rendszert írjatok! Ja, hogy nincs hozzá elég tapasztalat/tudás/idő/anyám tyúkja? Megesik! Akkor használd azt, ami van, és aki meg tudja mit akar, azt hagyd menni!

Másrészt, a sysvinit még unixra íródott, ami azért erősen experimental cucc volt, és nem a bolondbiztos használatra találták ki. Aki hozzányúl, tudnia kell mit csinál, mert ráfaraghat.

Vicces itt ez a mondat hogy "nem egységesek".. Mikor egy újabb csodás FORK van a láthatáron ;)

2015* lesz a Linux Desktop éve, mert lassan egy 100 gépes környezetben akár 100 különféle forkolt linux distrot lehet majd telepíteni ;)

ps.: és még elvárni olyasmit hogy egységes ... nevetséges.

Ha Gentoo-t használsz, akkor szinte tetszőleges számú gépre tudsz eltérően összerakott OS-t telepíteni :) A Linux Desktop éve szerintem akkor fog eljönni, amikor tényleg elfogynak az IPv4-es címek, és csak IPv6-os címet fognak tudni kiosztani a következő internetre kapcsolt gépnek. Bár lehet, hogy ez utóbbi hamarabb be fog következni :-D

( Nextra | 2014. 10. 21., k – 12:23 )

-- offtopic --
Látom sokan értik a systemd-t és bár nem ide tartozik amit írok, valaki igazán elárulhatná step by step hogy mit csináljak ha a létező legkevesebb cuccot szeretném elindítani. Gondoltam a 4-es initre, hogy az lenne az amit indítok, de abba nem kell más mint amire szükségem van. Ezek a billentyűzet, numlock, cron, at, hozzáférés a hanghoz, és a videóhoz. Ha például tévékártyáról szeretnék felvenni éjszaka, akkor egy minimal init bőven elég. Nem kell az egész lakásban felkapcsolni a villanyt, elég csak az egyik szobában.
Az biztos hogy ezt a sysvinit-ben nekem mint NEM rendszergazda, sokkal egyszerűbb volt megoldani. Még csak szerkesztgetnem sem kellett.
Csak azokat az initeket hagytam a 4-esben amikre szükségem volt. Ezt most nem tudom hogyan kell.
Jól gondolom-e ha létrehozok egy runlevel4.target.wants-ot az /etc/systemd/system mappába.
És ebbe runlevel4-be meg bele szimlinkelem az acpid, alsa-state, alsa-restore, atd, basic, crond, rc-local dolgokat, és ennyi.
A grubban meg meg tudom adni hogy melyik init induljon el.
De ha nézem a basic.target.wants-ot abban meg iptables dolgok vannak. Tehát a basic nekem sem jó, mert gondolom akkor annak a tartalmát töltené be. Na szóval nekem egyelőre bonyolult.
-- offtopic end --

Felejtsd el a runlevelt, systemdben nincs olyan. Csinálj egy új targetet, amelybe azokat a szolgáltatásokat teszed, amelyek kellenek. És bootolj abba a targetbe.

Ave, Saabi.
ps: pongyola megfogalmazással éltem, de még tanulom én is a systemdt, ráadásul tanfolyamon vagyok, arra kellene figyelni. :-D

"A systemd jól dokumentált" - valaki linkelte a doksikat is... Szerintem boot-olj be valami régebbi Linuxot pendrive-ról, ami még normális initet használ, és használd azt, amíg nem lesz a systemd annyira dokumentált, és nem lesz vele közel annyi tapasztalat, mint az alig dokumentált, iszonyatosan bonyolult sysvinit :-D

( uid_4656 v | 2014. 10. 21., k – 13:26 )

Évezettel olvasom a témát.

Egy elég erős érvelési hibát azért sok esetben felfedezni vélek, amit az alábbi, képzelt párbeszédben tudnék összefoglalni:

- Az én saját szemszögemből nézve nekem nem kell a systemd.
- De számos olyan dologhoz, ami nem látszik a Te szemszögedből tök jó a systemd.
- De én azokat nem is akarom látni, ezért a systemd rossz.

:-)