Vlákno názorů k článku
TrueOS přechází na OpenRC
od backup - otevrene file descriptory - sysV init
lrwx------ 1 root...
-
backup (neregistrovaný)
otevrene file descriptory - sysV init
lrwx------ 1 root root 64 Jan 24 19:08 10 -> /dev/initctlto same systemd
lrwx------ 1 root root 64 24. Jan 17:56 0 -> /dev/null
lrwx------ 1 root root 64 24. Jan 17:56 1 -> /dev/null
lr-x------ 1 root root 64 24. Jan 17:56 10 -> /proc/swaps
lrwx------ 1 root root 64 24. Jan 17:56 11 -> socket:[15563]
lrwx------ 1 root root 64 24. Jan 17:56 12 -> anon_inode:[timerfd]
lrwx------ 1 root root 64 24. Jan 17:56 14 -> socket:[24537]
lrwx------ 1 root root 64 24. Jan 17:56 15 -> socket:[1224]
lrwx------ 1 root root 64 24. Jan 17:56 16 -> socket:[1235]
lrwx------ 1 root root 64 24. Jan 17:56 17 -> socket:[1238]
lrwx------ 1 root root 64 24. Jan 17:56 18 -> socket:[15570]
lrwx------ 1 root root 64 24. Jan 17:56 2 -> /dev/null
lr-x------ 1 root root 64 24. Jan 17:56 27 -> /dev/autofs
lr-x------ 1 root root 64 24. Jan 17:56 3 -> anon_inode:inotify
lrwx------ 1 root root 64 24. Jan 17:56 39 -> socket:[16250]
lrwx------ 1 root root 64 24. Jan 17:56 4 -> anon_inode:[eventpoll]
l-wx------ 1 root root 64 24. Jan 17:56 40 -> /dev/kmsg
lrwx------ 1 root root 64 24. Jan 17:56 41 -> socket:[1240]
lrwx------ 1 root root 64 24. Jan 17:56 42 -> socket:[15200]
lrwx------ 1 root root 64 24. Jan 17:56 43 -> socket:[15585]
lrwx------ 1 root root 64 24. Jan 17:56 44 -> socket:[15584]
lrwx------ 1 root root 64 24. Jan 17:56 45 -> socket:[15203]
lrwx------ 1 root root 64 24. Jan 17:56 46 -> socket:[15206]
lrwx------ 1 root root 64 24. Jan 17:56 47 -> socket:[15207]
lrwx------ 1 root root 64 24. Jan 17:56 48 -> /run/dmeventd-server
lrwx------ 1 root root 64 24. Jan 17:56 49 -> /run/dmeventd-client
lrwx------ 1 root root 64 24. Jan 17:56 5 -> anon_inode:[signalfd]
lrwx------ 1 root root 64 24. Jan 17:56 50 -> /dev/initctl
lrwx------ 1 root root 64 24. Jan 17:56 51 -> socket:[15577]
lrwx------ 1 root root 64 24. Jan 17:56 52 -> socket:[15602]
lrwx------ 1 root root 64 24. Jan 17:56 53 -> socket:[12545]
lrwx------ 1 root root 64 24. Jan 17:56 54 -> socket:[12546]
lr-x------ 1 root root 64 24. Jan 17:56 55 -> pipe:[15590]
lr-x------ 1 root root 64 24. Jan 17:56 6 -> /sys/fs/cgroup/systemd
lrwx------ 1 root root 64 24. Jan 17:56 7 -> anon_inode:[timerfd]
lrwx------ 1 root root 64 24. Jan 17:56 8 -> socket:[15560]
lr-x------ 1 root root 64 24. Jan 17:56 9 -> /proc/1/mountinfoa to jen systemd s pid=1
V poctu otevrenych descriptoru vede systemd jasne pred SAP a Oracle
-
Ondra Satai NekolaZlatý podporovatelVzhledem k tom, ze systemv nefunguje...
Jak moc drahy resource je vlastne ten filedescriptor?
-
Ondra Satai NekolaZlatý podporovatel
Tak kdyz uz chces prudit na tohle tema... tak zkus zapocitat naklady na bambilion spousteni shellu v klasickych init resenich.
-
Co to s lopatou melete za blbosti? Spousteni sluzeb je u systemd uplne stejny jako u klasickyho initu a stejny jako u jakyhokoli jinyho initu v UNIXu. Spusti se shellovej skript kterej spusti danou sluzbu. shellovej script se po startu sluzby ukonci a parrentem procesu se stane init. Tak to funguje u System V init, OpenRC, Runit, Systemd i SMF u Solarisu. Jedinej rozdil u Systemd a SMF je ze je tam navic textak popisujici jak presne se ma ten script (pripadne kontrolni exac treba apachectl) spoustet.
-
lopata (neregistrovaný)
Ale prosímtě, ty vůbec nevíš, jak systemd funguje a jenom šíříš FUD. Systemd nespouští žádný shell, ale spouští service přímo jako proces. Těch možností, jak to může udělat, je spousta, doporučuju nastudovat https://www.freedesktop.org/software/systemd/man/systemd.service.html# konkrétně option Type.
systemd navíc umí socket activation, který ještě více šetří zdroje pokud chceš, tohle shell based inity neumí vůbec a musíš na to vzít další komponentu (inetd).
-
Ja vim presne jak systemd funguje. Uz sem nejen pro nej par servicu delal. Type je jen nastaveni supervisoru. Nijak to neresi, veci jako nastaveni prostredi, zmeny uzivate atd. Sice tam mas ExecStartPre, ale psat do toho naky pre checky ci cleanup to by bylo dost pro masochisty.
Cili pro par service presne navrzenych systemd to neusetri nic, protoze to misto shellovyho scriptu otevre textak. A pro cokoli se slozitejsim spoustenim to veme dvakrat vic file deskriptoru, protoze krome spousteciho scriptu musi nejdriv ten textak, aby ten script vubec nasel.A to ze se usetri jeden file deskriptor na inetd, kdyz si to otevre 20 dalsich fakt nemuzes myslet vazne...
-
lopata (neregistrovaný)
Aha, takže otevřít textový soubor a ten přečíst je podle tebe stejná režije, jako spustit bash a spustit v něm skript, který teprve spustí aplikaci?
Jinak mně je jedno, že nemáš rád systemd, ale nešiř o něm prosím FUD a nepravdy, systemd opravdu žádný bash pro spuštění service nepotřebuje a nespouští. Tvoje tvrzení bylo nepravdivé.
-
Nesirim FUD jen rikam jak to je. Tech servicu kterych start up script potrebuje je porad hodne a to cislo se nikdy blizit nule nebude.
Mas pravdu, ze pokud ten textak parsuje primo systemd pri startu, tak na ukor permanentniho naroku na pamet teoreticky v idealnim pripade nemusi spoustet dalsi interpret (shell) pokud to sluzba nevyzaduje.
To uz ale neplati pri manualnim spousteni sluzeb, kdy je narok vzdy minimalne stejny ci vyssi nez u klasickyho initu.systemctl + .service (+ shell + script) + samotnej service
vs.
shell + script + service
Kazdopadne vsechno pohle je naprosto bezpredmetny, protoze ten script bezi vzdy par sekund, takze v realu systemd nenabizi vubec zadnou vyhodu na ukor pameti a slozitosti...
-
Ondra Satai NekolaZlatý podporovatel
To mas jednoduche: Vezmi si dva podobne systemy - se systemd a s nejakym prainitem a nastartuj je. Podivej se na PID sveho login shellu.
-
Ondra Satai NekolaZlatý podporovatel
@BR
Na to, kolik doopravdy systemd spousti shell scriptu resp kolik je potreba procesu na nastartovani systemu.
-
OK, muzu porovnavat debian se systemd, kde bezi ssh, httpd a proxy oproti openwrt s busyboxem, kde bezi ssh, httpd, pppd, hostapd a dnsmasq
Debian ukazuje po startu posledni PID 1647
openwrt ukazuje PID 1676.Kde ze je tech "bambilion spousteni shellu v klasickych init resenich", ktery systemd usetri?
-
systemd navíc umí socket activation, který ještě více šetří zdroje pokud chceš, tohle shell based inity neumí vůbec a musíš na to vzít další komponentu (inetd).
Cim presne je lepsi pouziti komponenty systemd namisto jine komponenty (inetd)? Ten systemd to jaksi nedela zazracne zadarmo, ale ma na to zase nejaky ten necod, ktery tam musi bezet misto initd a otazka je, jestli to dela nejak lepe nebo usporneji.
-
lopata (neregistrovaný)
A proč by to nemohlo být i v systemd? Uživatelé to asi chtějí, tak je to i v systemd. Co bude nebo nebude v systemd závisí jen na poptávce uživatelů a ochotě přispěvatelů to do systemd implementovat. Nebo už je problém i v tom, že systemd implementuje nějakou funkcionalitu? Chtěl bys to nějak direktivně řídit, rozhodovat o tom, co v systemd bude a nebude? Můžeš, pošli patch na odstranění podpory socket activation ze systemd, pokud s tím máš problém a nechceš to. Obavám se ale, že takový patch komunita nepřijme.
-
Soft limit je uplne neco jinyho. Soft limit a hard limit se uplatnuje na uzivatele (ulimit) a s nastavenim jadra nema nic spolecnyho.
Limit v jadre je prave to na co si odkazoval a ma zabezpecit stabilitu jadra. Samozrejme muzes si to menit, ale jako u spousty dalsich nastaveni jadra se pak nesmis divit az ti zacne padat... -
skeptik (neregistrovaný)
Zase šíříš FUD... Proč by mělo začít jádro padat? Změna file-max je naprosto standardní operace, která se provádí z user space, není důvod, aby cokoliv padalo.
Tvůj původní argument o tom, že systemd otvírá desítky descriptorů a něco v jádře by mohlo dojít je naprosto směšný, to se ti snažím vysvětlit. Zaprvé v jádře žádný limit není a zadruhé omezení, které si můžeš sám nastavit, je bežně řádově ve stovkách tisíc descriptorů.
-
Koukam, logicky mysleni neni tvoje silna stranka co?
Proc myslis, ze to nastaveni vubec v jadre je? Pro strandu kralikum?
Maximalni pocet file deskriptoru muzes menit, ale ne nijak dramaticky, protoze moc vysokym pocem ohrozujes stabilitu pocitace (resp. muze vycerpat volnou pamet).
Linux Dokumentation project doporucuje 256 filedeskkriptoru na 4MB pameti.
http://tldp.org/LDP/solrhe/Securing-Optimizing-Linux-RH-Edition-v1.3/chap6sec72.html
Cili je to omezeny resource a ne ze ne. To ze ten limit je bezne ve stovkach tisic sem nikde nerozporoval...
ČLÁNKY DO MAILU