- A hozzászóláshoz be kell jelentkezni
- 2116 megtekintés
Hozzászólások
mint init rendszer tetszik a systemd. de az, hogy lassan mindenbe belenyul amihez semmi koze (pl. dns) az mar nem.
- A hozzászóláshoz be kell jelentkezni
A manuális +1-ed azt a hamis látszatot kelti, mintha te nyomtál volna a hozzászólására +1-et. A másik én voltam. Egyébként még nyomhatsz rá... :)
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
Jah, bocs, el is felejtettem hogy az új motor már tudja. :)
"Sose a gép a hülye."
- A hozzászóláshoz be kell jelentkezni
Csak két lehetőséget látok a systemd melletti szavazásra:
1. Fasz se tudja mi ez, de 200+ birka csak nem tévedhet.
2. gyerekkori bántalmazásból eredő beteges perverzió
:D
- A hozzászóláshoz be kell jelentkezni
3. Leszarja a hosszas okoskodásokat, örül annak, hogy van benne egy rakás hasznos feature, mindenütt ugyanúgy néz ki, és nem kell shell scriptet írni, sem "start on started" jellegű agyzsibbasztó baromságokat.
- A hozzászóláshoz be kell jelentkezni
Mint cloudos fejleszto baromi kenyelmes dolgok vannak benne, amikor mondjuk egy kesz rendszert kapunk, amihez hozza kell igazitani valamit. Pl ha ezt szeretnem, hogy X elott meg lefusson valami, es mondjuk nem erdekel, hogy sikeres volt-e a futas attol meg X induljon el. Ez systemd-ben egy ket soros file. Vagy mondjuk ha Y ujraindul, induljon ujra Z is, vagy masik user neveben, ... nagyon hosszu a lista.
- A hozzászóláshoz be kell jelentkezni
Szerintem csak a szavazás van szerencsétlenül kiírva ezzel a „kedvenc” jelzővel. 200+ embernek nem kedvenc egyáltalán, hanem csak ezt használják. Ezzel jön a disztró, amit használnak, használják, ami be van építve, nem akarnak széllel szemben hugyozni. Biztos vagyok benne, hogy szeretni nem szeretik ennyien. Rá vannak kényszerülve a használatára, egyszerűen csak használják.
Nekem az initrendszer egyébként mindegy, csak ne systemd legyen, és lehetőleg tudja a szolgáltatásokat párhuzamosan betölteni a gyorsabb boot érdekében. Most vagyok átállóban Arch + systemd kombóról Gentoo + openrc kombóra. Egy szemléletes példa: Arch alaprendszer boot után konzolban 100 MB memóriát eszik. Gentoo openrc-vel 29 megát! Ennél többet nem is kell mondani a systemd-ről, nem szorul egyszerűen kommentre.
“The world runs on Excel spreadsheets.” (Dylan Beattie)
- A hozzászóláshoz be kell jelentkezni
Nekem egy picit furcsa, hogy az érintetteknél is jobban tudod, ők mit szeretnek, nekik mi a kedvenc...
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
Hagyd, vele és TCHval nem érdemes erről beszélni, szerintük a systemd a patásördög, és elhozza az opensource meg a linux végét, nem fér bele a világképükbe, hogy esetleg ezt valaki szereti, és tudatosan tetszik neki, nem csak megvezetett birka.
- A hozzászóláshoz be kell jelentkezni
Egyáltalán nem. Az igaz, hogy véleményem szerint szar, de én pragmatikusan közelítem meg a helyzetet. Aki használ olyan szoftvert, ami annyira dependel rá, annál teljesen megértem, hogy nem akar alternatív initrendszerrel szívni, hanem használja a systemd-t, főleg ha már úgyis default azzal érkezik a disztrója. Ebben semmi hibát nem is látok, ha én lennék ebben a helyzetben, akkor talán még én is így csinálnám. De nekem azért az egy kicsit erős, hogy mindjárt érzelmileg is „kedvenc”. Nem is értem mit lehet rajta szeretni. Főleg ez initrendszeren, aminek csak az a dolga, hogy a kernel után betöltse a rendszer alapelemeit. Nekem ez kicsit furcsa fetisizmusnak tűnik, ha valaki ebbe van beleszerelmesedve. Azért is írtam, hogy nekem az initrendszer elvileg mindegy, egyiket se szeretem, használom azt, ami nekem jobbnak, kevésbé bloatnak tűnik, és törekedek rá, hogy lehetőleg az ne systemd legyen. Ennyi, nem kell ebbe túl sokat belelátni.
Azt még el is hiszem egyébként pár perverz emberről, hogy kifejezetten rajongója a systemd-nek, de 200+ szavazónál erősen kétlem.
“The world runs on Excel spreadsheets.” (Dylan Beattie)
- A hozzászóláshoz be kell jelentkezni
"Nem is értem mit lehet rajta szeretni" a hozzaszolasod felett is kifejtettem. a rugalmassagat es testreszabhatosagt lehet szeretni pl.
"aminek csak az a dolga, hogy a kernel után betöltse a rendszer alapelemeit" igen, ami nem 1 dimenzios tortenet, hanem leteznek fuggosegek, egyutt ujrainditando dolgok, service inditast megelozo lepesek, stb.
"pár perverz emberről" ez nem perverzio kerdese. Amikor valami config management cuccal automatizalni kell rendszerek uzemelteteset, akkor baromira kapora jon, hogy distro fuggetlenul leteszek egy service update filet a megadott helyre, es full controlom van a serviceim felett anelkul, hogy egyetlen script filet is megvaltoztatnek.
Pont a multkor futottam bele egy ilyenbe, Csinaltunk egy egyszer futo servicet, aminek Docker daemon utan kellett elindulnia, ujra kellett indulnia amikor a docker ujraindult, raadasul ujraindulas kozben ki kellett takaritani valamit az elozo futasbol, plusz egy 3rd party servicehez is csatlakozott, szoval ha nem sikerult neki elindulnia, akkor tobbszor is meg kellett probalni. Es miutan sikeresen lefutott, valamilyen formaban perzisztalni kellett, hogy lefutott. Ezt kb 5 perc alatt osszehoztuk egy unit fajlban egy sor script nelkul (es egy sor script teszt nelkul). Kb. After, Requires, One Shot, ExecStartPre, Restart, RemainAfterExit. Raadasul ha valaki megis meg akarna valtoztatni, csak overrideolja amit akar.
- A hozzászóláshoz be kell jelentkezni
csak az a dolga, hogy a kernel után betöltse a rendszer alapelemeit
Nem csak az a dolga. Függőségek, hibakezelés - újrainduljon? Hányszor? Time out? -, különféle timer-ek kezelése, például bekapcsolás után valamennyi idővel indítson automatikus upgrade-et, illetve heti egyszer legyen fstrim, és így tovább. Nem olyan rossz az, csak szerintem nem ismered. Arra is van lehetőség, hogy felülírsz unit file-t úgy, hogy nem szerkeszted a default-ot, így egy frissítés nem rontja el, de azt is lehet, hogy a default-hoz képest kiegészítéseket írsz hozzá.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
Jó, akkor fogalmazzuk úgy át, rendben betöltse a rendszer elemeit. Ezeket, amiket írtál, tudja az OpenRC is. Egyébként magával az initrészével a systemd-nek még nem is lenne akkora bajom, a gond az, hogy sok mindent saját szakállra dönt el, meg egy csomó bloat hozzá van csomagolva már, rég nem csak egy initrendszer, egyfajta user space mini OS lett. Semmi baj nem lenne vele, ha megmaradt volna initrendszernek, és nem dependelnek rá mindent, nem kényszerítik be minden disztróba. Tőlem elférne, ha csak egy +1 alternatíva lenne.
“The world runs on Excel spreadsheets.” (Dylan Beattie)
- A hozzászóláshoz be kell jelentkezni
Igen, a topic első hozzászólására én is nyomtam +1-et. :)
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
Kíválló megfogalmazás! Hogy kell értékelni? Ha rányomok a +1-re , átvált -1-re
- A hozzászóláshoz be kell jelentkezni
Nyilván. Egyszer szavazhatsz +1-gyel, ha már szavaztál, lehetőséged van visszavonni, ezért lesz -1.
- A hozzászóláshoz be kell jelentkezni
Timer pont nem jó példa, pl 44 éve létezik cron - ami nem romlott el ne akarjuk megjavítani.
- A hozzászóláshoz be kell jelentkezni
Inkább az anacronra gondoltam.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
azt hogy lehet abban beallitani hogy boot utan 42 sec mulva futtason le egy progit?
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
- A hozzászóláshoz be kell jelentkezni
Mint minden trükkös kérdésre, erre is a sleep a valasz :-)
- A hozzászóláshoz be kell jelentkezni
És a cron az tudni fog arról, hogy a függőséged életben van? :) Ugye ott tartunk, hogy az alkalmazásodnak van egy lehetősége reportolni a systemd felé, hogy healthy és ez alapján tud további dolgokat tenni a systemd.
- A hozzászóláshoz be kell jelentkezni
pl. meg tudja nézni a pid fájlt (a program/script amit a cron indít).
- A hozzászóláshoz be kell jelentkezni
Tarts egy kis önvizsgálatot, mert sajnos de. Az nem pragmatikus, hogy aki használja, az ha normális, akkor max elviseli, és ha kedveli, akkor meg perverz.
- A hozzászóláshoz be kell jelentkezni
Valakinek még az is igénye, hogy esetleg az elindítsán túl még esetleg próbálja meg életben is tartani a rendszert és/vagy úgy indítsa el a dolgokat, hogy azok használhatóak is legyenek meg a többi.
- A hozzászóláshoz be kell jelentkezni
Nagyjából emiatt nem szavaztam ebben a kategóriában. Jelenleg minden gépemen systemd fut, mert ez a disztribúció alap init rendszer (Debian, Arch), viszont nem mondanám, hogy kedvenc lenne. A systemd alap elgondolása tetszik, az, hogy magába olvasztott egy csomó olyan funkciót, ami nem egy init rendszer feladata, az nagyon nem. A sysvinitet hasznátam a maga összes problémájával, az upstartról nem győztem elmenekülni, a többit viszont nem, vagy csak érintőlegesen ismerem. De szerintem más is képes eldönteni a saját szempontrendszere alapján, hogy szavaz-e, és hogy mire. Ahogy a többi kategóriában is.
- A hozzászóláshoz be kell jelentkezni
A systemd alap elgondolása tetszik, az, hogy magába olvasztott egy csomó olyan funkciót, ami nem egy init rendszer feladata, az nagyon nem.
A probléma az, hogy a systemd-re mint init rendszerre hivatkozik mindenki. Ha az volna jogos volna az érv, hogy túl sokat tud egy init rendszerhez. De nem az. Ezt írják róla a freedesktop.org-on: "systemd is a suite of basic building blocks for a Linux system.".
Talán sántít a hasonlat, de az ablakkezelők -> asztali környezetek kapcsolatát lehetne idevenni. Egy asztali környezet jóval több dolgot tud és csinál mint csak egy WM. És ez nem is baj.
- A hozzászóláshoz be kell jelentkezni
Illetve kíváncsi lennék hogy aki ilyen-olyan okokkal megpróbálja racionalizálni a shitstemd imádatát, az próbált-e már egy olyat a listából (pl. s6, runit, nosh), ami djb mester daemontoolsából merít
let's go Brandon!
- A hozzászóláshoz be kell jelentkezni
hat koszi szepen, de djb munkassagabol inkabb nem kerek, szoptam vele epp eleget az evek soran... szerencsere mar kikoptak es csak nagyon elvetve talalkozni az emlekevel is
- A hozzászóláshoz be kell jelentkezni
A koncepcióval voltak bajok, vagy az implementációval? Előbbi esetén mik? Nem biztos, hogy pl. skarnet (s6) elkövette ugyanazokat a hibákat.
- A hozzászóláshoz be kell jelentkezni
supervise pedig nem volt egy rossz dolog
- A hozzászóláshoz be kell jelentkezni
én próbáltam már:
- a runit szerintem hányás, folyamatos fájdalom :)
- az s6 egyébként a kedvenc listám második helyén van, mert át van gondolva, jó értelemben vett minimalista, és kudos a chainloading startégiáért, szóval kalap le a benne levő engineeringért (még ha személy szerint nem mindent gondolok annyira fekete-fehérnek, mint emberünk), de azért használni nem szeretem.
- Openrcnek anno a wikipédia oldalán elakadtam, már nem emlékeztem miért. Ránéztem megint, gondolom azért, mert a példa samba service 62 két sornyi shell script rajta. Szóval n+1edik randomdistro sysvinit fölé tákolt shellhalomjának látszik, a pötyi bácsinak meg igaza van a deklaratív konfig fileokkal. Komolyan, ilyeneket kellene beleírni?
# szabványos újraindító függvény reload() { ${my_service_PRE} signal_do reload } - Többit nem néztem, az utolsót most jól megnéztem, bazmeg javascript.
- A hozzászóláshoz be kell jelentkezni
> openrc
semmi koze a daemontoolshoz, sem az abbol epitkezo tobbihez
> javascript
he?
let's go Brandon!
- A hozzászóláshoz be kell jelentkezni
> openrc
semmi koze a daemontoolshoz, sem az abbol epitkezo tobbihez
És hol mondtam én olyat, hogy lenne?
he?
- A hozzászóláshoz be kell jelentkezni
ahh, te az OPban levo osszesrol beszelsz, en csak azokrol amiket a hozzaszolasomban felsoroltam
let's go Brandon!
- A hozzászóláshoz be kell jelentkezni
Oh, elnézést, gondolom a bejgli rövidre zárta a parseremet, és nem fogtam fel, mit írtál. Igen, az összesről beszéltem. Viszont akkor szegény s6nak köze van a daemontoolshoz (azt sem szeretem, érdemei elismerése mellett)
- A hozzászóláshoz be kell jelentkezni
Üzemeltetőként nem tudom, hogy milyen az openrc, de használni egyszerű volt anno amikor Gnetoot használtam. Tiszta átlátható logikus koncepció, és szépen kezelte a függőségeket.
- A hozzászóláshoz be kell jelentkezni
Szerintem simán használni ezeket mind egyszerű. Be is tenne, ha már az is bonyolult lenne, hogy foobar start|stop|restart vagy valami alternatív ige, mert az jó. Igazából szerintem mindnek van service wrappere, szóval ha 92 körül megtanultad, hogy "service akármi restart", akkor az most is jó :D
A systemd valóban felrúg még egy két dolgot: leállíthatatlan waiting for stop job, mert a magic sysreq nem jó, journalctl defaultból, skandallum, és még a nohupos otthagyott random futó szarokat is kitakarítja, ha kilép a shell, blaszfémia (az, hogy helyette ad normális módot arra, hogy lehessen tudni, mi a fenét hagyott ott valaki oldalágon odabaszva az initnek, hogy majd csinálj vele valamit, az meg ugye senkit nem érdekel), a szélesebb feature készlet miatt, de azért -- szerintem -- messze nem targédia.
Az openrcvel ránézésre annyi a bajom, hogy n+1-dik próbálkozás arra nézve, hogy adjon egy shell toolingot ezeknek a kezelésére. Még az is lehet, hogy jobb (végül is, volt miből levonni a konzekvenciákat), de igazából a nagy hozzáadott értéket azért nem látom, és az biztos, hogy nem akarok 60 soros scriptet írni ahhoz, hogy el lehessen indítani, meg le lehessen állítani egy rohadt daemont. Ráadásul az egyik fele olyan, hogy egy jobb reggelen szebbet "készítek" még a kv előtt ( eval cmd_exec=\$${daemon}_${signal} pfejj) , a másik fele meg boilerplate. És ahol a rendszer része az, hogy boilerplate kell, ott minden jólelkű programozónál el kellene kezdeni villogni a piros lámpának fejben, hogy nagyon nem sikerült eltalálni az absztrakciót.
- A hozzászóláshoz be kell jelentkezni
Tök érdekes , amit írsz. Nekem mint usernek kb. úgy jött le a dolog, hogy használtam disztrokat sysvinit-tel, és hát igen értem meg minden, de valahogy az openrc volt a (user oldalról) a legáttekintehtőbb és a függőségkezelés miatt a legegyszerűbb is. Aztán jött a systemd és csak az a kérdés merült fel bennem, hogy "Mi ez a kaotikus szar?"
Ma úgy látom, hogy a systemd által betöltött (vagy betölteni kavánt) funkcionalitásra nyilvánvalóan szükség van, és itt nem elsősorban az init rendszerre gondolok. De az is nyilvánvaló, hogy a systemd ezt távolról sem jól valósítja meg.
Szóval nagyon jó lenne egy systemd alternatíva, ahol az egyes részfunkciók között szabványosított interface van, és így minden egyes részt szépen ki lehet váltani, vagy az igények szerint összeváloganti. A jelenelgi systemd konglomerátum így ebben a formában ezekkel a hibákkal és ilyen fejlesztési filozófiával tényleg egy jelentős problémává nőtte ki magát.
- A hozzászóláshoz be kell jelentkezni
> Szóval nagyon jó lenne egy systemd alternatíva, ahol az egyes részfunkciók között szabványosított interface van, és így minden egyes részt szépen ki lehet váltani, vagy az igények szerint összeváloganti.
Az s6 kb. ezt csinálja, csak nem önti bele az egészet az initbe, szétbontható az egész, úgy rakod össze, ahogy neked jó, amúgy UNIX-osan és teszi ezt hordozható módon, tehát minden POSIX rendszerre jó és nem egyetlen bloated Linux-only blob az egész. De ahogy nézem a bra-ket által említett nosh is hasonló koncepciójú, bár ott csak a BSD-ket és a Linuxot említi a szerző, mint célplatformot.
- A hozzászóláshoz be kell jelentkezni
Ránéztem, elég ígéretes. Ahogy így elnéztem van legalább 2 arch linux variáns, ami csak arra jött létre, hogy alternatív init rendszert nyújtson. A kipróbálásig nem jutottam, de azért elvileg van kész megoldás, ha a mainstream mégis szabadulna a systemd-től. Igen tudom, hogy AUR-ból jelenleg is több opció elérhető, de azért ezekhez a dokumentáció enyhén szólva is hiányos.
- A hozzászóláshoz be kell jelentkezni
A doksikat a fejlesztő(k) oldalán kell keresni, az s6-nak pl. elég jó doksija van. Arra viszont egy darabig ne számítsunk, hogy a systemdtől annyira szabadulna a mainstream; tavaly még csak-csak rá lehetett mondani, hogy egyenlő arányban vannak az ellenzők és a támogatók, hiszen 1 nyamvadt szavazaton múlott, hogy a systemd-nek abszolút többsége lett, de most annak ellenére, hogy többen szavaztak, most egyértelműen abszolút többséggel vezet eddig a systemd, tehát a helyzet csak romlott... Kiváncsi leszek holnap a Debianosok szavazásának eredményére.
- A hozzászóláshoz be kell jelentkezni
Szóval nagyon jó lenne egy systemd alternatíva, ahol az egyes részfunkciók között szabványosított interface van, és így minden egyes részt szépen ki lehet váltani, vagy az igények szerint összeváloganti.
Az ugye megvan, hogy minden systemd-* (meg maga a systemd) alapvetően D-Buson kínál API-t a nagyvilágnak, ami egy introspektálható, standardizált megoldás: vagyis annyi a dolgod, hogy fogod lekéred az implementált interfészt, írsz rá egy implementációt, és öröm és boldogság.
BlackY
"Gyakran hasznos ugyanis, ha számlálni tudjuk, hányszor futott le már egy végtelenciklus." (haroldking)
- A hozzászóláshoz be kell jelentkezni
Hát persze, ilyen egyszerű. Oh wait, lehet, hogy mégsem? https://en.wikipedia.org/wiki/Systemd
- A hozzászóláshoz be kell jelentkezni
Pontosabb hivatkozást, esetleg idézetet meg tudnál osztani? Ez elég sok egyben.
- A hozzászóláshoz be kell jelentkezni
Ha megnézed a két ábrát, akkor látszik, hogy nem a dbus (kdbus) az egyetlen interface. A másik, hogy az interface specifikáció is lehet rossz, nem csak az implementáció. Egy rossz interfacere nem lehet jó szolgáltatást építeni.
- A hozzászóláshoz be kell jelentkezni
Javíts ki, ha tévedek, de én úgy tudom, hogy a systemd nem egyszerűen magától a D-Bus protokolltól függ, hanem egészen konkrétan a kdbus D-Bus implementációtól, ami nem volt része a kernelnek és még javában folytak a viták a kernelfejlesztők között, hogy melyik bus alternatíva váltsa a régi BUS1-et és a kdbus finoman szólva sem tartozott a favoritok közé, de ekkor a FreeDesktop Team közölte, hogy ha systemd-t akarnak futtatni, akkor ez és kész. És mivel akkorra már a disztrók többsége systemd-függő volt, a kernelfejlesztők lenyelték a békát és így sikerült egy újabb FreeDesktop komponenstől függővé tenni az egész Linux ökoszisztémát.
- A hozzászóláshoz be kell jelentkezni
Nembaj, googlék megfejtették a dns over https implementációval, hogy úgy is le lehet szarni, amit az OS gondol az ügyben. :/
- A hozzászóláshoz be kell jelentkezni
- A hozzászóláshoz be kell jelentkezni
Mert -- egyébként együtt a mozzilával, csak őket én kevésbé látom fajsúlyosnak, a google sokkal egyszerűbben tolja le mindenki torkán a saját elképzelését a világról -- implementálták a supportot bele a böngészőbe, úgy, hogy hát majd használja a rendszer névfeloldását, ha akarja, meg amikor akarja, egyébként meg nem. Ez szerintem egy rendkívül káros gyakorlat. Félre ne érts, én is írtam már olyan kódot, ami maga intézte a névfeloldást bizonyos esetekben, de az egy speciális eset, egy általános kliensprogramban ilyet elkövetni finoman szólva is nem elegáns.
Bár nagyon érintőlegesen néztem még a témát, de úgy tűnik, hogy vicces módon az MSnek sikerült ezt oda tenni, ahova való: bele a system resolverbe. Nembaj, majd pöttering megírja a resolvedbe, és lehet még jobban utálni :D
Szóval nem magával a protokollal van baj, hanem azzal, hogy hova tették. (Illetve azt még szintén meg kéne néznem, hogy egyébként mi a fenétől jobb ez bármivel, mind a dnssec)
- A hozzászóláshoz be kell jelentkezni
amihez semmi koze (pl. dns) az mar nem
Jajúristen, szemét systemd, hogy a fejlesztője kihasználva, hogy csomó plumbing már meg van, így gyorsan összeüthet egy resolvert, megcsinálta a systemd-resolved-ot :( Persze hogy a használatához többször kell opt-inelni (csomag feltelepítése, szolgáltatás engedélyezése, nsswitch-be és/vagy resolv.conf-ba felvitele), az már egy olyan apróság, amivel nem foglalkozunk...
BlackY
"Gyakran hasznos ugyanis, ha számlálni tudjuk, hányszor futott le már egy végtelenciklus." (haroldking)
- A hozzászóláshoz be kell jelentkezni
"olyan apróság, amivel nem foglalkozunk..."
mivel a disztrok mar megcsinaltak helyettunk...
persze szerencsere le lehet szedni. most meg le lehet...
- A hozzászóláshoz be kell jelentkezni
Mutass már egy disztrót, ami default bekapcsolva hozza a systemd-resolved-ot. Akár csak egy olyat, ami default _telepíti_.
BlackY
"Gyakran hasznos ugyanis, ha számlálni tudjuk, hányszor futott le már egy végtelenciklus." (haroldking)
- A hozzászóláshoz be kell jelentkezni
szerintem en centos-ben talalkoztam vele valamikor (es tuti nem en raktam fel), de gugli alapjan ubiban is:
https://askubuntu.com/questions/907246/how-to-disable-systemd-resolved-…
ugy tunik a networkmanager hozza magaval?
- A hozzászóláshoz be kell jelentkezni
masfel honapja telepitett centos7-en "csak" ezek futnak by default:
root 1 0 0 2019 ? 00:31:28 /usr/lib/systemd/systemd --switched-root --system --deserialize 22
root 386 1 0 2019 ? 01:02:33 /usr/lib/systemd/systemd-journald
root 413 1 0 2019 ? 00:00:00 /usr/lib/systemd/systemd-udevd
root 565 1 0 2019 ? 00:01:55 /usr/lib/systemd/systemd-logind
resolved nincs. de udevd? logind? wtfd?
- A hozzászóláshoz be kell jelentkezni
itt egy par napja telepitett ubi 18.04 lts server ps-e:
root 422 1 0 Jan02 ? 00:00:01 /lib/systemd/systemd-journald
root 457 1 0 Jan02 ? 00:00:05 /lib/systemd/systemd-udevd
systemd+ 728 1 0 Jan02 ? 00:00:00 /lib/systemd/systemd-timesyncd
systemd+ 950 1 0 Jan02 ? 00:00:00 /lib/systemd/systemd-networkd
systemd+ 973 1 0 Jan02 ? 00:00:00 /lib/systemd/systemd-resolved
message+ 1121 1 0 Jan02 ? 00:00:31 /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation --syslog-only
root 1236 1 0 Jan02 ? 00:00:15 /lib/systemd/systemd-logind
root 3047 1 0 09:47 ? 00:00:00 /lib/systemd/systemd --user
- A hozzászóláshoz be kell jelentkezni
f31 -en nem latom ezeket (nem friss install, upgrade).
chrony az ajanlott NTP.
Networkmanager az ajanlott network config.
systemd-resolved nincs ajanlas, unbound gyakran hasznalat.
systemd-machined viszont van, aminek nem sok ertelmet latom.
Amit nem lehet megirni assemblyben, azt nem lehet megirni.
- A hozzászóláshoz be kell jelentkezni
Linux Mint 19 (~Ubuntu 18.04). Nem kértem, hogy telepítse, nem nyúltam hozzá, és ott figyel a "vendor preset: enabled" is:
$ systemctl status systemd-resolved
● systemd-resolved.service - Network Name Resolution
Loaded: loaded (/lib/systemd/system/systemd-resolved.service; enabled; vendor preset: enabled)
Active: active (running) since [...]
$ lsb_release -a
No LSB modules are available.
Distributor ID: LinuxMint
Description: Linux Mint 19.3 Tricia
Release: 19.3
Codename: tricia
$- A hozzászóláshoz be kell jelentkezni
megneztem egy nemreg 18-ra upgradelt 16.04-et is amin 1000% hogy nem volt resolvd az upgrade elott, es most azon is van, szerencsere a resolv.conf-ba nem irta bele magat de amugy fut.
ugyhogy megforditanam a kerdest: mutass egy recent distrot, ami systemd alapu es nincs rajta default resolved...
- A hozzászóláshoz be kell jelentkezni
Az összes fentire: jogos, Debian tényleg szarul csomagolja és a teljes systemd ernyőprojektet berakja egybe (így az összes származéka is); de használva nincsen.
BlackY
"Gyakran hasznos ugyanis, ha számlálni tudjuk, hányszor futott le már egy végtelenciklus." (haroldking)
- A hozzászóláshoz be kell jelentkezni
dehogynincs hasznalva:
root@btk-mailgw2:~# cat /etc/resolv.conf
# This file is managed by man:systemd-resolved(8). Do not edit.
#
...
# See man:systemd-resolved.service(8) for details about the supported modes of
# operation for /etc/resolv.conf.
nameserver 127.0.0.53
options edns0
root@btk-mailgw2:~# systemctl status systemd-resolved
* systemd-resolved.service - Network Name Resolution
Loaded: loaded (/lib/systemd/system/systemd-resolved.service; enabled; vendor preset: enabled)
Active: active (running) since Thu 2019-12-26 23:35:48 CET; 1 weeks 4 days ago
- A hozzászóláshoz be kell jelentkezni
Én a sysvinit-et látom át. Az esetek 98%-ában ez tökmindegy, mert megy minden magától, de van olyan launchd elem amit 10+ éve nem bírok leírtani a gépemről. Baj mindig maradék 2%-ban van. De biztos jó csak ennyi év alatt se jöttem rá néhány dologra benne :)
- A hozzászóláshoz be kell jelentkezni