Egy vicces értelmezés szerint arra utal, hogy a systemd 500 komponensből áll ...
- 3522 megtekintés
Hozzászólások
Deszar...
- A hozzászóláshoz be kell jelentkezni
Szvsz az ötszáz azért elég sovány a valósághoz képest... Ha még tudnánk gondolkozni, és tudatosítanánk, hogy egy önértékelés terén súlyos kihívásokkal küzdő ember (aka hybris) konkrétan mindenbe belenyúl, ami a rendszerünkben fut, sikítva menekülnénk.
- A hozzászóláshoz be kell jelentkezni
Szerencsére senki sem közvetlenül használja a termékét, hanem a disztróján keresztül. Tehát előtted már sokan átnézték a kódot, és jónak találták ahhoz, hogy bekerüljön.
Az nem véletlen, hogy gyakorlatilag mindenki systemd-re állt át. Persze, lehet mindenki hülye, de valami alapjának legalább kell lennie, különben nem használnák.
Amúgy meg ugyanez pepitában a macos launch -ja, meg a dózerben is van valami hasonló, most nem jut eszembe a neve.
Egész egyszerűen kellett valami, ami figyel változásokra, és triggerel dolgokat, amikor megtörténnek. Persze lehet 129 különálló szervert indítani egyesével erre, de egyszerűbb összefogni egy rendszerbe, és elnevezni "event handler and reconciler"-nek, vagy akár röviden systemd-nek. :D
- A hozzászóláshoz be kell jelentkezni
> Tehát előtted már sokan átnézték a kódot, és jónak találták ahhoz, hogy bekerüljön.
Ó te kedves, nyári gyermek.
> Persze, lehet mindenki hülye, de valami alapjának legalább kell lennie, különben nem használnák.
Hype. Legfőképp.
> Egész egyszerűen kellett valami, ami figyel változásokra, és triggrel dolgokat, amikor megtörténnek. Persze lehet 129 különálló szervert indítani egyesével erre, de egyszerűbb összefogni egy rendszerbe, és elnevezni "event handler and reconciler"-nek, vagy akár röviden systemd-nek. :D
Cserébe single point of failure-é válik ez a rendszer. Azaz ha itt valami hiba van, akkor nem tudod megkerülni, nem tudsz megoldást adni, csak imádkozhatsz. Normális supportja nincs, mert hát openszósz. Amúgy az eseménykezelésre ő is az uDevD-t használja, tehát ez pont nem a SystemD feladata.
- A hozzászóláshoz be kell jelentkezni
A sima /sbin/init is single point of failure. És ugyanúgy nincs normális supportja, mert openszósz.
Melyik rendszerre igaz az, hogy az init nem spof és van supportja?
- A hozzászóláshoz be kell jelentkezni
Egy initrendszer esetén a support hogy néz ki szerinted? Mert pl. Windows alatt mondjuk a Notepad-nek van normális supportja? Ezt szerintem nem egészen gondoltad át.
“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”
- A hozzászóláshoz be kell jelentkezni
Ő panaszkodott arra, hogy a systemdnek nincs supoortja. Csak épp azt elfelejtette hozzátenni, hogy pont annyira nincs a többi init rendszernek sem, ez nem megkülönböztető tulajdonsága a systemdnek.
- A hozzászóláshoz be kell jelentkezni
Lépj vissza a kezdőmezőre: pont az a baj, hogy a systemd nem init-rendszer, hanem a Nagy Univerzális Minden program.
- A hozzászóláshoz be kell jelentkezni
Hogy mi? Mi ez a fszsag? Az init az ami, a PID 1 program. Legközelebb már valami filozófiai értelmezésbe megyünk át? Miért keverjük az érzelmeket a tényekkel? Nekem tök mindegy, szereted e, vagy se, ettől még ez egy init program, és a feladatát is ellátja.
- A hozzászóláshoz be kell jelentkezni
Szóltak már neked a systemd-vel érkezett bináris logfájlokról, vagy ez még a jövő zenéje?
- A hozzászóláshoz be kell jelentkezni
A syslognál sem definiált, hogy a logfájl az bináris vagy nem, a szabvány sem írja elő a plain textet.
A syslog-ng is tudja binárisan is tárolni a logokat, ha úgy állítod be.
Ha te logokat akarsz olvasni, akkor nem egyértelmű, hogy azt tudod-e plaintext kezelő eszközökkel olvasni, mert a rendszerben bármikor lehet bináris a logfájl, nem definiált, hogy az, vagy nem az.
- A hozzászóláshoz be kell jelentkezni
> A syslognál sem definiált, hogy a logfájl az bináris vagy nem, a szabvány sem írja elő a plain textet.
Akkor olvasd át a szabványt. Már a fejlécnél is 7 bites ASCII kódolásról beszélnek, legfejlebb az üzenet lehet bináris.
> A syslog-ng is tudja binárisan is tárolni a logokat, ha úgy állítod be.
A journald viszont alapból nem tudja plantextben tárolni a fájlokat. Azért van textual representation egyáltalán a legtöbb disztróban, mert az rsyslog felnyalja a journald által kifosott bitkolbászt.
> Ha te logokat akarsz olvasni, akkor nem egyértelmű, hogy azt tudod-e plaintext kezelő eszközökkel olvasni, mert a rendszerben bármikor lehet bináris a logfájl, nem definiált, hogy az, vagy nem az.
Ez biztos valami modern mentalitás, mert az alkalamzások döntő többségének amúgy van plantext logja, amit szabad szemmel is lehet olvasni. Csak néhány kereskedelmi alkalmazásnál láttam eddig, hogy kizárólag bináris blobokat állított elő. Jobbára inkább a kivételek szintén fordult ez a SystemD/JournalD páros előtt ez elő, a hibahatár alatt.
- A hozzászóláshoz be kell jelentkezni
Akkor olvasd át a szabványt. Már a fejlécnél is 7 bites ASCII kódolásról beszélnek, legfejlebb az üzenet lehet bináris.
Van szabvány a log formátumra? Lemaradtam valamiről? Az RFC5424-ben valóban van ilyen, de az az on wire protokoll, köze nincs a logfileokhoz et al.
- A hozzászóláshoz be kell jelentkezni
Nézd, egy ideje a szakmában vagyok, volt és van változás mindig. Az él túl aki nyitott ezekre. A jót próbáld ebben meglátni.
JFYI: Normális rendszereknél a logokat nem az adott hoston dolgozzák fel.
- A hozzászóláshoz be kell jelentkezni
> JFYI: Normális rendszereknél a logokat nem az adott hoston dolgozzák fel.
Annyira szeretem, amikor ilyen féligazságokkal dobálóztok. Persze, kizárólag mindenhol csak enterprise rendszerek léteznek, óriási architektúrába szervezve. Olyan pláne még csak véletelenül sincsen soha, hogy meggebed a hálózat, és lokálisan, az adott hoston kellene logokat olvasni debugolás céljából. Ami hálózatot mellesleg alapból sokszor szintén a SystemD egyik bugos alrendszere orchestrál.
Ne akarjuk már validálni azt, ami józan ésszel ránézve az architektúrára agyfasz. Van egy csomó jó és hasznos feature-e a SystemD-nek, ezt elismerem bármikor, de attól még se nem jó konstrukció, se nem jó szoftvertermék. És míg annak idején a SysV initet meglepően gyorsan ki lehetett cserélni akár egy Bash scripthalmazra is, addig manapság mindenbe beleeszi magát a SystemD/DBus függőség, ha ki akarod szedni a rendszerből, lényegében nem lehet. Ezzel szenved az OpenRC is egy ideje, ki tudják váltani a SystemD-t, de... és jönnek azok a részfunkciók, amiket mindenképp be kell emelni, hogy egyáltalán eljusson a rendszer a login promptig. Ehhez képest az upstart maga volt a pőre igénytelenség szobra, carrarai márványból.
Én nyitott vagyok a változásokra is, nem véletlenül tanultam bele a Kubernetesbe is. De attól nem lesz valami kevésbé szar.
- A hozzászóláshoz be kell jelentkezni
Annyira szeretem, amikor ilyen féligazságokkal dobálóztok. Persze, kizárólag mindenhol csak enterprise rendszerek léteznek, óriási architektúrába szervezve.
Nem, mondom normális rendszereknél. A rendszer nem 1db számítógép ha már van 3 géped akkor sem helyben dolgozod fel. Lehetnek kivételek, de ez a 99.99%-ra igaz.
Olyan pláne még csak véletelenül sincsen soha, hogy meggebed a hálózat, és lokálisan, az adott hoston kellene logokat olvasni debugolás céljából.
És szerinted a log forwarder mit csinál? Nincs hely ideiglenes tárolás? De az nem a feldolgozásra vonatkozik, hanem a működésre. Ha olyan helyzetet akarsz alapesetként kezelni "meggebed a hálózat" ami egy hibás működés, akkor el vagy tévedve. Nekem ne gyere azzal légyszi, hogy a logok akkor kellenek ha baj van.
Én nyitott vagyok a változásokra nem véletlenül tanultam bele a Kubernetesbe is.
Akkor talán alkalmazhatnád is, mert pl. az egy jó példa, miért nem kell helyben feldolgozni a logokat.
- A hozzászóláshoz be kell jelentkezni
Most még init program, de mivel kisgömböcként falja fel a linuxot, maholnap a systemd lesz az egész oprendszer. Ne feledjük, hogy a Windows is csak egy shell volt valaha, most meg ugye... :-)
- A hozzászóláshoz be kell jelentkezni
Én pedig nem látom, hogy valaki is a felhasználók belenyugvása nélkül könnyen meg tudná tenni. Itt nem CEO dönt, bármikor csinálhatsz egy saját disztribúciót.
- A hozzászóláshoz be kell jelentkezni
Már megtörtént dolgokról beszélünk. Gyakorlatilag nincs olyan disztró, ami teljesen SystemD független lenne, még ha ezt is állítja magáról. Sure, az init rendszer OpenRC, de egy csomó kis modulka kell a SystemD-ból, mert az opensource világ ráült a hype vonatra.
- A hozzászóláshoz be kell jelentkezni
Amikor 1db valamiből tudsz "választani" akkor ne vágj pikacsu arcot. Csinálj alternatívát.
- A hozzászóláshoz be kell jelentkezni
Abban azért igazat adok neki, hogy valaha volt egy KISS filozófia, amit a systemd síkosító nélkül dugott fenékbe, és ezt látva jogosan fintorodik el az ember.
- A hozzászóláshoz be kell jelentkezni
A régi világ nem akkor tűnt fel amikor megjelentek az integrált dolgok, hanem amikor a nyivákolás lett hangosabb a tenni akarásnál. Ha neki ez igazán fontos lenne, akkor tenne valamit, addig míg nem az és senki se mozgatja a fenekét, addig "jóvanezígy". Lehet keseregni, de semmi értelme.
- A hozzászóláshoz be kell jelentkezni
Nekem a devuanban még nem tűnt fel, lehet rossz vonatra szálltam?:)
- A hozzászóláshoz be kell jelentkezni
A systemd projekt részei közül semmit sem kötelező használni, sem a resolved, homed, journald stb. Semennyire sem kell használnod. Ha a disztribúció úgy dönt, hogy használja, akkor pedig tőlük kapsz támogatást rá.
Amúgy különítsük el azt, hogy systemd-t mint szoftvert értjük (ami az init rendszer és service manager)vagy a systemd-t mint projektet értjük, az alá tartozó egyéb szoftverekkel (systemd-homed, systemd-resolved és társai).
- A hozzászóláshoz be kell jelentkezni
Mmint erről az egészről sokat elmond, hogy egyrészről van ez a vélemény, hogy mert csúnya monolitikus izé, amiben minden IS benne van, másrészről meg a videó legjobb része, hogy a D bizonyára azt az ötszáz komponenst jelenti, amiből áll :)
- A hozzászóláshoz be kell jelentkezni
Az a baj, hogy nem egyértelmű név, a systemd jelenti magát a sok komponensből álló projektet és magát az init/service managert.
- A hozzászóláshoz be kell jelentkezni
Ez valóban nem segít, de azért nem ez az egyetlen oka. Egyrészt van ez az ideológia basz, hogy túl sok minden van túl összefonódva benne, másrészt meg vannak ennek egyértelmű előnyei a gyakorlatban (meg a hátrányai is nyilván). Nyilván nem segít Pöettering főni csudálatos stílusa se, meg hát azért volt benne bugi is rendesen (természetesen a minden másban is), meg hát a featureök minősége is változó, van néhány kifejezetten jó része, néhány elég fos, a többség kissé hintázik a meh, good-enough vonalon (tegnap pl nem először szembesültem azzal, hogy hát jó ez a journalctl, de azért így helyenként lehetne flexibilisebb). Összességében nem egy igazán "szerethető" szoftver.
Imho a nemszeretem bagázs azért szeret kevésbé fontos dolgokat túlfújni, meg azért néha nem látják a fától az erdőt. Amikor minden egyben van, akkor pfujj, mert a unix way az a do one thing but do it well, miért van benne ennyi minden a systemd-ben, a másik oldalon meg mikor pl a DEk úgy vannak vele, hogy ők inkább írnának DE-t akkor, és basszon nyugodtan a session managementtel pl a logind, nem tartanak karban ugyanarra mind egy-egy saját megoldást, számukra marginális területen, akkor meg az a baj, hogy jajjdependency....
Ezzel együtt, azért tény, hogy rendesen széttarabolni részeit egyáltalán nem triviális, valószínűleg alternatívákat biztosítani és karbantartani se az, nyilván nem véletlen nem sokan csinálják.
- A hozzászóláshoz be kell jelentkezni
De hát pont azért áll sok komponensből a systemd projekt, hogy UNIX elvek mentén composable legyen a rendszered. És felépítheted a rendszeredet a SysV komponensek helyett systemd komponensekből. Egyáltalán nem látom a problémát, nem egy monolitikus szar. Az más kérdés, hogy egy olyan sok komponensből álló rendszer, amit egységes elvek mentén, együttműködésre terveztek. De hát ilyen minden kereskedelmi UNIX is manapság.
Nekem nincs problémám azzal, ha valaki SysV stílusú rendszert szeretne, de azért lássuk be, az elmúlt 35 évben rájöttünk arra, hogy annak milyen hátrányai, kényelmetlenségei, korlátai vannak. Pont ezeket akarja a systemd projekt megugrani, és adni egy egységesen kezelhető alaprendszert, ami a GNU komponensek mellett oprendszert csinál.
Talán ahhoz tudnám hasonlítani, hogy míg a *BSD projektekben az egyes OS-szintű eszközöket a projekt maga fejleszti, addig a GNU/Linuxnál ez sosem volt így, és a systemd projekt pont ezt akarja megcsinálni. És akkor lehet rá tényleg dependálni, szépen UNIX módra összelegózni a funkcionalitásokat - csak éppen a legózás egyes elemeit ugaynaz a "gyár" állítja elő, és nem ezerféle implementációra kell felkészülnie a dependens szoftvereknek.
Azt akarja kezelni, ahol a POSIX szabványosítása már véget ér, és meg vannak lőve a fejlesztők, hogy na akkor most mit is feltételezhetünk a runtime-ról, mit és milyen formában biztosít a szoftveremnek.
- A hozzászóláshoz be kell jelentkezni
Teljesen egyetértünk, én is így látom a helyzetet, épp a két megmondás közötti ellentmondásra akartam felhívni a figyelmet, hogy hát kissé van-e rajta sapka helyzet van.
És jepp, azt nem írtam, de egyébként valóban pontosan az a legjobb benne, hogy ez egységes elvek mentén, összedolgozásra van (és ezt nem szokták érteni azok, akik a túl bonyolult, és össze van nőve, nem elég elkülönült darabokból van állásponton vannak). Hogy a darabjai lehet hogy meh, a timerek lehet hogy kevésbé tetszenek mint egy cron, meg bonyibbnak tűnnek, cserébe össze vannak nőve rendesen a service managementtel, nem kell körbevarázsolni. Hogy lehet, hogy resolved pfujjpfujj, mert beletolakodik a resolve.confba, és "nem tudod mi történik" (egyébként de), meg vannak miatt szopások (hello docker és resolve.conf másolgatás), cserébe amikor a network manager felhúz egy openvpnt, akkor a split tunnel beállítások alapján beállítódik magától a megfelelő resolve routing. Meg ilyenek.
- A hozzászóláshoz be kell jelentkezni
Másik hasonló téma, amit a POSIX nem fed le, és jó lenne rá valamilyen normális egységes megoldás, az azok a problémák, amikre a freedesktop.org próbál választ adni. Sokan szidják azt is, pedig ha nem lenne, még nagyobb káosz lenne.
- A hozzászóláshoz be kell jelentkezni
Ez biztos? Én még nem hallottam arról hogy journald nélkül menne a systemd. Tudtommal az egy elég hard dependency. A -homed meg -resolved, meg pár társa valóban opcionális.
Régóta vágyok én, az androidok mezonkincsére már!
- A hozzászóláshoz be kell jelentkezni
- A hozzászóláshoz be kell jelentkezni
Tegyük hozzá, hogy ettől még fut az, csak kevesebb dolgot csinál, de továbbra is átmászik rajta minden is.
- A hozzászóláshoz be kell jelentkezni
Nem, nem megy át rajta minden, te nyugodtan logolhatsz máshová, nem kötelező a journald-t használnod. Nem várja el senki tőled, hogy egy systemd-s rendszeren használjad kötelezően a journald-t logolásra.
- A hozzászóláshoz be kell jelentkezni
Elolvasva a linkelt KB cikket, nekem pont úgy néz ki, hogy a journald továbbra is ott van, továbbra is fut, és minden log ami a _systemd-ben keletkezik_ a journald-be megy. Csak éppen a bináris logfájlját nem írja, hanem azonnal forwardolja az rsyslogd-nek.
Az egy teljesen másik kérdés, hogy az alkalmazásaidat/service-eidet a saját konfigfájljaikkal külön konfigurálhatod, hogy máshova logoljanak (ha támogat ilyet). Illetve - ha van erőforrásod karbantartani a service file overlay-eket minden vicik-vacak service-re - akkor persze egyedileg eltérítheted a default stdout/stderr logolását journald-től máshova. De ettől még a journald nem szűnik meg a systemd kötelező függőségének lenni, ellenben sok más systemd-szatelit vackokkal, amik tényleg opcionálisak.
Régóta vágyok én, az androidok mezonkincsére már!
- A hozzászóláshoz be kell jelentkezni
Idéznék belőle:
Edit the journald configuration at /etc/systemd/journald.conf; switch journal to in-memory only mode and enable forwarding:
[Journal]
Storage=none
ForwardToSyslog=yes
Create drop-in for the rsyslog unit configuration file at /etc/systemd/system/rsyslog.service.d/logging.conf with the following content to ensure socket creation and linking:
# https://access.redhat.com/articles/4058681
[Unit]
Requires=syslog.socket[Install]
Alias=syslog.service
Load the drop-in file, and restart services:
Raw# systemctl daemon-reload
# systemctl enable rsyslog.service
# systemctl restart rsyslog.service
# systemctl restart systemd-journald.service
Man:
ForwardToSyslog=, ForwardToKMsg=, ForwardToConsole=, ForwardToWall=, ForwardToSocket=
Control whether log messages received by the journal daemon shall be forwarded to a traditional syslog daemon, to the kernel log buffer (kmsg), to the system console, sent as wall messages to all logged-in users or sent over a socket.
A man nem írja le értelmesen, hogy ez konkrétan a syslog.socketet jelenti, de mi mást jelentene (különös tekintettel, hogy bool value a forwardtosyslog)
Szóval de, a journald service fut, és keresztülfolyik rajta minden, ő teszi ki a syslog socketre.
Szerk: Ha azt szeretted volna mondani, hogy egyéb dolgokat irányíthatok direktben a syslogra, az természetesen igaz. Csak hát ez azt nem támasztja alá, hogy a systemd menne a journal nélkül (tippre ha kikapcsolod menni fog, de a felőle jövő logok rohadtul nem fognak kijönni sehogyse)
- A hozzászóláshoz be kell jelentkezni
# systemctl restart systemd-journald.service
Kikeresed magadnak hogy mi a különbség a disable és a restart között, vagy megtegyem neked? A SystemD nem működik journald nélkül, és ezt a KB cikk is elég nyilvánvalóvá teszi, miután sehol nem tiltja le a journald-t. Az továbbra is fut a memóriában, és átmegy rajta lényegében minden fontosabb üzenet, csak in-memory marad. Azért van ez így, mert a SystemD nem képes működni journald nélkül.
De győzz meg az ellenkezőjéről, bizonyítsd be, hogy ha letiltod teljesen a journald-t, akkor utána a SystemD boldogan átvált rsyslogra. Mert ezt jelentené az úgynevezett modularitás.
- A hozzászóláshoz be kell jelentkezni
Kikeresed magadnak hogy mi a különbség a disable és a restart között, vagy megtegyem neked?
Nem kell, tudom. Pontosan ezért emeltem ki, hogy persicsb kollégának is feltűnjön, hogy az ő linkjén is egy restart van, szóval futni fog a journald.
Nem lenne baj, ha alacsonyabb lovat keresnél, ha már ennyire nem sikerült megérteni, amit írtam. Egészen konkrétan le is írtam, hogy ettől még nincs letiltva, és a systemd dolgainak kell.
- A hozzászóláshoz be kell jelentkezni
Azaz ha itt valami hiba van, akkor nem tudod megkerülni, nem tudsz megoldást adni, csak imádkozhatsz.
Mi van? Melyik init rendszernél nem így van? Mikor adtál meg más init binary-t kernel bootsorban legutoljára?
Normális supportja nincs
Azt ugye tudod, hogy az RHEL és az Ubuntu is systemd-vel van szállítva? Én értem, hogy semminek értékeled az enterprise támogatást, de attól még nagyon nincs rendben amit írsz.
i.e.: lehet a systemd-t szeretni/nem szeretni, lehet azon is dühöngeni, hogy nincs igazi versenytársa, de azért a tényeket nem kellene elferdíteni.
- A hozzászóláshoz be kell jelentkezni
Opensource esetén közösségi support van, illetve megfikszálhatod a problémát magadnak. Ha ennél többet szeretnél akkor ki kell fizetni az enterprise supportot.
- A hozzászóláshoz be kell jelentkezni
"Hype. Legfőképp." szamos funkciojat hasznalom, es tok orulok, hogy ezek egybe vanna gyurva. Melyik masik init rendszernek van ekkora rugalmassaga? Es itt nem arra kell gondolni, hogy ossze lehet-e kalapalni valami hasonlot. Hanem arra, hogy distro fejleszto vagy, netan serviceket fejlesztesz. Baromi kenyelmes, hogy "mas userrel kell fusson", "kell neki delay", "egy uj fuggoseg kell" stb. Odapattintom a konfigot, es akkor ugy megy. Szinte barmilyen distron.
deathstar? Igen. De ez kb minden feature rich cuccra igaz egy ido utan.
- A hozzászóláshoz be kell jelentkezni
Meglepett a válasz, azt hittem én is, hogy d=deamon. Nem mintha számítana.
“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”
- A hozzászóláshoz be kell jelentkezni
Gondolom, csak poén.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE- A hozzászóláshoz be kell jelentkezni
Lehet én értek félre valamit, de szerintem a videó komoly, és tényleg az a-c verziók utáni verzió. Fura, de hihető. Bár abban igazad van, hogy legyünk fenntartással, lehet valami kamu AI-s videó is, ami csak hitelesnek látszik.
“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”
- A hozzászóláshoz be kell jelentkezni
didló
- A hozzászóláshoz be kell jelentkezni
D, mint "Disaster". Tegnap 2x próbáltunk DR-t egy szerveren (REAR-rel szépen ment vissza SLES15 SP6-ra, ott se indult el az SAP, csak néha) SLES15 SP7 upgrade után nem indult el az SAP(csak néha, mint a mesében), vagy az SAP vagy a SystemD hibás, vagy mind azok. :)
- A hozzászóláshoz be kell jelentkezni
Off: ebből csak annyit értek hogy a tényleges programindítás megkönnyítőprogramok sorozatán át történik, a hibaüzenetek (ha vannak) eltűnnek a semmiben, a debuggolás kb. lehetetlen.
- A hozzászóláshoz be kell jelentkezni
Ebből a leírásból nekem annyi látszik, hogy az üzemeltetőkben van a hiba.
- A hozzászóláshoz be kell jelentkezni
Nekem az SAP-hoz 0 közöm van. Systemd fejlesztő sem vagyok. Akkor hol van a hiba??
- A hozzászóláshoz be kell jelentkezni
Üzemeltetőként benned.
- A hozzászóláshoz be kell jelentkezni
Az SAP saját magának generálja systemd service fájlokat, hozzáérni tilos. Látom kiválóan értesz ehhez is.Fogalmad nincs erről sem.
- A hozzászóláshoz be kell jelentkezni
Tegnap 2x próbáltunk DR-t egy szerveren (REAR-rel szépen ment vissza SLES15 SP6-ra, ott se indult el az SAP, csak néha) SLES15 SP7 upgrade után nem indult el az SAP(csak néha, mint a mesében),
Erre vonatkozik a megállapításom, hogy üzemeltetésből elégtelen. Az, hogy te ezt személyes sérelemként dolgozod fel, az a saját szociális problémád.
- A hozzászóláshoz be kell jelentkezni
Ennek pont az ellenkezője igaz.
- A hozzászóláshoz be kell jelentkezni
DR-t tudatosan rendszerszinten csinálnak és ugyanazt állítják vissza ami volt, és ugyanúgy kell mennie, ahogy előtte ment. Ha ez nem garantálható, akkor ott komoly gondok vannak az üzemeltetéssel, mert vagy a DR forrás nincs megfelelően létrehozva és frissítve (életciklus követés) vagy az üzemeltetés képtelen szoftveresen konfigurálni a környezetet és barkácsolnak.
- A hozzászóláshoz be kell jelentkezni
Az esetek 99%-ban ilyenkor az történik hogy valamelyik resource nincs 100% pontosan fixálva (tipik példa a docker image hash vagy verzió nem-fixálása) és akkor lejön a latest és akkor reccs.
- A hozzászóláshoz be kell jelentkezni
Akkor az életciklus hibás, valaki a szőnyeg szélére áll.
- A hozzászóláshoz be kell jelentkezni
Nem, a leírásból annyi látszik, hogy mind a systemtré, mind a SAP egy fos, és nehéz különválasztani, hogy melyik okozza a gondot. Nyilván valahol skill issue is, de aki ilyen szutykokkal dolgozik, az rá is van szorulva a csoda skill-ekre, az tuti.
“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”
- A hozzászóláshoz be kell jelentkezni
Nem új telepítésről beszélt hanem egy DR-ről. Annak pedig pont ugyanúgy mennie kell ahogy az előtte ment. Ha nem úgy megy, akkor szar a DR mentés, vagy a DR visszaállítási procedura.
- A hozzászóláshoz be kell jelentkezni
Bár nem tudom jelen esetben mi a konkrét probléma forrása - lehet, hogy a konkrét service file-ban van elrontva valami -, de az általános tapasztalatom nekem is hasonló.
Ha tényleges reliability kell, mondjuk HA corosync, ill pacemaker clusterrel... Vagy akárcsak egy periodikus healtcheck és watchdog automatikus újraindításhoz... Na akkor kezdenek a systemd service management bugjai előmászni a sötétből.
Addig tkp egész jól lefedi az alap használati eseteket (jobban, mint ahogy anno SysV vagy BSD init scriptekben bármilyen tákolással meg lehetett oldani), de a HA-környéki használati eseteknél kiütköznek a 15+ éves, azóta sem javított bugok. Megbízhatatlan systemd-notify, és emiatt fals módon triggerelődő watchdog és társai... A Wants=, DependsOn= stb. függőségkezelés anomáliái. Hogy nem tudod rendesen megoldani, hogy melyik visszatérési érték számítson "retry-olós hibának", melyiknél adjuk fel azonnal és hagyjuk failoverelni amilyen gyorsan csak lehet. Ilyenkor tényleg az szokott a vége lenni, hogy ki kell venni az adott service-t (service tree-t) a systemd kezelése alól.
Régóta vágyok én, az androidok mezonkincsére már!
- A hozzászóláshoz be kell jelentkezni
Alapvetés, ha a problémában a SAP felmerül, mindig az a hibás :D
- A hozzászóláshoz be kell jelentkezni
A systemd azt csinálta nagyon ügyesen, hogy annak a néhány funkciónak a farvizén ami hiányzott a korábbi megoldásokból gyakorlatilag az összes defacto apit lecserélte. Dbus a hagyományos IPC-helyett, ini stílusú konfig fájlok a - mondjuk itt nehéz viszonyítási pontot találni :) - szokásos unixosak helyett.
- A hozzászóláshoz be kell jelentkezni
Dbus a hagyományos IPC-helyett
Mondjuk a dbus jocskan kulturaltabb, de legalabbis modernebb az shm-nel.
Az IPC igazabol mindig is egy can of worms volt, tipikusan volt ra 200 eltero megoldas, es mindenki masikat hasznalt.
ini stílusú konfig fájlok a - mondjuk itt nehéz viszonyítási pontot találni :) - szokásos unixosak helyett.
A neve toml, es mar a rust is bevezette, mert olvashatobb, mint a json, de messze primitivebb/egyszerubb, mint a yaml.
A unix ini file-okrol kar is vitatkozni, a hajamat tudnam tepni, amikor mindegyiknek total mas formatuma van; na azert a vilagert nem kar.
- A hozzászóláshoz be kell jelentkezni
És valóban! Az INI nem kezel több szintű hierarchiát.
https://github.com/toml-lang/toml#comparison-with-other-formats
Azért amennyire követem a károgás nagyrésze a nem működő eseménykezelésből adódik. Hogy ennek mennyi köze a dbus-hoz, közvetlenül, arról fogalmam sincs.
- A hozzászóláshoz be kell jelentkezni
Azt nem, de azért nem raketa-tudomany, hogy mondjuk
[terminal_types]
type1=xterm
type2=putty
[terminal_type_xterm]
kbs=^H
kdel=^?
[terminal_type_putty]
kbs=^?
kdel=\e[3~- A hozzászóláshoz be kell jelentkezni
Arról megy az elmélkedés, hogy melyik a jobban olvasható, melyik az egyértelműbb? Egyszerűbb esetekben hajlok rá én is, hogy a TOML de bonyoloultabb eseteknél a table eléggé ocsmány tud lenni.
https://toml.io/en/v1.0.0#table
pl. ez a rész:
fruit.apple.color = "red"
# Defines a table named fruit
# Defines a table named fruit.apple
fruit.apple.taste.sweet = true
# Defines a table named fruit.apple.taste
# fruit and fruit.apple were already created- A hozzászóláshoz be kell jelentkezni
Lehet, hogy erről van szó, én csak egy példát hoztam arra, hogy az .ini (avagy .properties) formátummal is lehet hierarchikus adatokat tárolni, ha akarunk.
- A hozzászóláshoz be kell jelentkezni
(dup)
- A hozzászóláshoz be kell jelentkezni
Nem csak az a különbség, olvass tovább. Én egyébként kivételesen szeretem a TOML formátumot, lényegében INI, de jobban szabványosítva, nem csak a többszintű architektúra, de adattípusok, formátumok benne. Sokkal olvashatóbb, érthetőbb emberi szemmel, mint a YAML, JSON és társaik.
“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”
- A hozzászóláshoz be kell jelentkezni
Belül kicsit sírok. ;) Feletted Teve példája számomra pont azt mutatja szépen, hogy miért jó a yaml, ha szükség van a konfig (kulcsok) hierarchikus voltára és hogy ez csak egy "hack" tud lenni a toml-ben.
- A hozzászóláshoz be kell jelentkezni
Rénézésre teve az ini fájlokról írt, a toml a specifikáció szerint nagyon jól kezel hierarchiát.
- A hozzászóláshoz be kell jelentkezni
Az nálam a "hack" amit "kezelésnek" hívnak... :)
- A hozzászóláshoz be kell jelentkezni
Értem, de teve példája nem toml, hanem ini fájl.
- A hozzászóláshoz be kell jelentkezni
Nincs lényegi különbség szerintem.
- A hozzászóláshoz be kell jelentkezni
De pont, hogy van.
- A hozzászóláshoz be kell jelentkezni
Amíg mindkettő text állomány amit worst case lehet helyben töfködni vim -el, meg lehet üzemszerűen újragyúrni ansible -vel, és alkalmasint ha olyanom van akkor írok egy bash/python programot ami mindenhova azt generál ami oda való, addig tőlem akár lehet html* formátum is, abba sem halok bele.
Az egyetlen nehézség amikor két eltérő formátum között agyban váltani kell, hogy most hogyan is gondolkodjak vele, de ez ugyanaz mint amikor az ember C -ben ír valamit és a fejében olyan fogalmak vannak mint memória, pointerek, verem, függvény cím, és hirtelen kell egy bash script, ami teljesen máshogy működik, ugyanazt a feladatot teljesen máshogy kell megközelíteni agyban.
* Elvetemült gondolatom támadt, .rtf formátumban kéne minden konfigot rögzíteni, mert akkor egyben winword kompatibilis szép, céges fejléces, nyomtatóbarát dokumentáció lenne minden konfig. Oké, engem nem hat meg a nyomtatási kinézet, de az adminisztráció egyes területein dolgozók meg vannak veszve, ha nem a megfelelő betűtípust, méretet és a az aktuális céges fejlécet használja az ember. És még engem tartanak a fura IT -s csávónak az alagsorból... :-)
- A hozzászóláshoz be kell jelentkezni
Akkor inkább HTML és a megfelelő stylesheet. Sőt, akár XML is lehetne, megfelelő stylesheettel.
- A hozzászóláshoz be kell jelentkezni
Ez ilyen Vibe-LLMOPS? Mondjuk Rtf-ben tarolod a promptot, ami az aktualis ChatGPT/Deepseek verzioval legeneralja a megfelelo configot. Modositaskor csak atirod a promptot, ujrafuttatod a generalast, aztan mehet fel a config.
A strange game. The only winning move is not to play. How about a nice game of chess?
- A hozzászóláshoz be kell jelentkezni
Lassan feltaláljátok a literate programming modern verzióját... :D
- A hozzászóláshoz be kell jelentkezni
Hogyne lenne. Egy random ini fájlból nem tudsz például hierarchikus JSON-t készíteni, míg egy random toml fájlból igen, oda-vissza tudsz konvertálni JSON és TOML között teljesen egyértelműen, bármilyen alap struktúrát (list, map, table). Egy ini fájlnál erre nincs lehetőséged.
- A hozzászóláshoz be kell jelentkezni
kedvencem a kubernetes gitlab runner konfigja amikor egy jsonbe kell úgy beletuszkolnod egy toml-t hogy abban még majd adott esetben a helm csinál egy variable expansiont.
na ezt debugolni igazi női munka...
- A hozzászóláshoz be kell jelentkezni
Aranybánya a topic az IT-ageism tekintetében. :D
Az a csapat, amelyik munnyog az miatt, hogy 50 év felett már nem akarják alkalmazni a cégek, az tulajdonképpen ugyanaz a csapat, amelyik munnyog minden újdonság miatt és a legfőbb érve az újdonságokkal szemben az, hogy "bezzeg az én időmben" és ezzel meg is magyarázta, hogy miért nem akarják alkalmazni. :D
- A hozzászóláshoz be kell jelentkezni
Lehetne egy kompromisszum: az újdonságok közül a hasznosakat üdvözöljük szeretettel, az újítás az újítás kedvért kategóriát meg balkézzel a jobb váll fölött, de messzire.
- A hozzászóláshoz be kell jelentkezni
Nézd, ez nem egy idén kijött újítás, itt egy 15 éves projektről beszélünk, amit még mindig nem tudtok elfogadni, és azóta is monnyogtok miatta mindenhol, ahol előkerül... megöregedtetek és képtelenek vagytok befogadni új technológiákat.
- A hozzászóláshoz be kell jelentkezni
Azért a systemd sem érte még el minden célját, például, hogy mikor kijelentkezel a GUI-ból, akkor egy segítőprogram megsemmisítse az összes elindított folyamatodat, ideértve az atomreaktor hűtését felügyelő processzt.
- A hozzászóláshoz be kell jelentkezni
A "bezzeg az én időmben" az valóban egy rossz érv.
Ettől függetlenül létezhetnek objektív érvek is x y újdonságokkal szemben.
Adott esetben a "feleslegesen bonyolult" is egy legitim érv lehet.
- A hozzászóláshoz be kell jelentkezni
A bezzeg az én időmben nem működik, mert még tart az én időm. De halálom után ütős szöveg lesz, csak éljem meg! :-)
- A hozzászóláshoz be kell jelentkezni
Ezt ha 20 évvel ezelőtt írtad volna, simán egyetértenék. De azóta sajnos inkább a legtöbb területen visszafejlődés volt, nem fejlődés, most joggal munnyognak, hogy bezzeg. Persze volt fejlődés is, SSD-k, fájlrendszerek, virtualizáció, konténerizáció, verziókövetés, többszállúsítás, stb., de többségében inkább visszafejlődés, módszertanok, tesztelés, UI, stb. tekintetében.
Ez egyébként nem azért van, mert régen „mindenjobbvót” ©®, meg okosabbak voltak, hanem mert régen a kényszerűség hajtotta a fejlesztőket, hogy az akkori szűk hardverlimitekből a legtöbbet hozzák ki, hogy valóban használható legyen, használhatóan fusson, fenntartható legyen. Muszáj volt a szoftver koncepcióját átgondolni, minél egyszerűbbre írni.
Sajnos ez a negatív trend még folytatódik is, nem volt elég a romlás az elmúlt 20 évben, meg megyünk tovább le a lejtőn, AI-vel kódolás, megfelelő tesztelés hiánya, verzióhajhászat, mindennek az erőszakos webesítése, felhősítése, még lebutítottabb tablet UI mindenben, minden szoftver kémkedik, telemetriázik, reklámoz, adatfarmoltat, stb.. Már a szoftver sem a végfelhasználóé, inkább a bérlésre-felhősítésre mennek. Nem adok még 20 évet, ezt te is belátod, _Franko_-n, persze akkor majd te is megkapod, hogy 50 évesen ugatod a Holdat, és az milyen szánalmas, bezzeg a legújabb trendek...
“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”
- A hozzászóláshoz be kell jelentkezni
De azóta sajnos inkább a legtöbb területen visszafejlődés volt, nem fejlődés, most joggal munnyognak, hogy bezzeg.
A lófaszt van visszafejlődés, menj mai senior harmicasok közé, rájössz, hogy csak megöregedtél és már nem tudod befogadni az újdonságot. Az a visszafejlődés duma már az ókor óta létezik. :D
Nem adok még 20 évet, ezt te is belátod, _Franko_-n, persze akkor majd te is megkapod, hogy 50 évesen ugatod a Holdat, és az milyen szánalmas, bezzeg a legújabb trendek...
Én most 48 vagyok, 20 év múlva 68 leszek, nem látom igazából magamon, hogy ne érdekelnének továbbra is az újdonságok a szakterületemen... egy csomó volt kollégám viszont 35 körül megállt a fejlődésben, ami akkor volt, az fasza, ami azután lett, az mind rossz. Ezért van alapja az IT-ban az ageism jelenségének, mert hiába veszi fel a cég az ötvenes szakembert, ha az folyamatosan csak munnyog, hogy mindenszarlett, bezzeg 20 évvel ezelőtt, akkor aztán volt fejlődés, de akkor meg az akkori ötvenesek munnyogtak folyamatosan, hogy mindenszarlett, bezzeg 20 évvel azelőtt. Innen teljes indukció van, az változik csupán, hogy az illető mikor volt harmincas és akkor mi volt.
- A hozzászóláshoz be kell jelentkezni
Szerintem véglet, amit írtál. Én a többségen nem ezt látom. Hanem azt, hogy n+1 világmegváltó csodát láttak már, amikről utólag kiderült hogy fancy spanyolviaszok, több szívással. Ezért óvatosak, nem ülnek fel minden hype-nak.
Ha valaki nem akar lemaradni, akkor akár keserű szájízzel is, de menni kell a trendekkel. Evvan. Engem inkább az aggaszt, hogy egyre többeket (rookie-t és rókát is) csak a pénz motivál ebben a szakmában. Jóvanazúgy' minden is, csak fizessenek jól.
echo crash > /dev/kmem
- A hozzászóláshoz be kell jelentkezni
Szerintem véglet, amit írtál. Én a többségen nem ezt látom. Hanem azt, hogy n+1 világmegváltó csodát láttak már, amikről utólag kiderült hogy fancy spanyolviaszok, több szívással. Ezért óvatosak, nem ülnek fel minden hype-nak.
Baszki, egy 15 éves széles körben elterjedt eszközről megy a munnyogás napok óta. Nem egy hype vonatról vagy fancy spanyolviaszról van szó... ezt lehetett volna mondani 2010 körül a systemd-ről, talán még 2015-ben is, de utána? Milyen hype vonat? Milyen fancy spanyolviasz?
Ez a téma mutatja, hogy mennyire alapja van annak, hogy egy ötvenes ember kiöregedett a szakmából, mert már képtelen követni a világot és elkezdi pejoratív jelzőkkel felaggatni az új technológiákat.
- A hozzászóláshoz be kell jelentkezni
Azért a systemd sem érte még el minden célját, például, hogy mikor kijelentkezel a GUI-ból, akkor egy segítőprogram megsemmisítse az összes elindított folyamatodat, ideértve az atomreaktor hűtését felügyelő processzt.
- A hozzászóláshoz be kell jelentkezni
Szerintem az az értelme, hogy cáfolja az implicit állítást, miszerint a 'systemd csak egy init-rendszer; egy kész, kiforrott termék, amit csak használni kell, nem bírálni'.
- A hozzászóláshoz be kell jelentkezni
Ezt a faszságot már másodszor írod le, mit szeretnél vele mondani?
Egyébként meg dehogynem, a logind pont ezt csinálja, hangosan ment is a nyekergés, hogy nem lehet csak úgy nohup-pal háttérbe tolni a screent meg a tmuxot, mert az a genya lelövi, és mit képzelnek...
- A hozzászóláshoz be kell jelentkezni
Az írásaidból 30-as körül gondoltalak, de ezek szerint 4 évvel még nálam is idősebb vagy, úgyhogy értened kéne, amiről beszélek. Átláttál, megéltél annyi trendváltozást, hogy a mai hype nem kéne, hogy elvarázsoljon. Pont azért, amit itt utánam is írtak, hogy a 40-50-esek láttak már egy csomó hype-ot annak idején is, hogy X OS meg Y világmegváltó nyelv, módszertan majd minden problémát megold, aztán nem, csak feltalálták újra a kereket, meg utána ki is mentek a divatból. Közben meg a legtöbb szabvány, formátum, *nix rendszerek elvei, nyelv, protokoll, stb. 30-40-50 évvel ezelőttről vannak, és ma is helytállók. Ami normális dolog, az nem avul el, hanem kiállja az idő próbáját, legfeljebb kicsit még alakul. Jól öregszik. Ez nem azt jelenti, hogy bizonyos területeken nincs fejlődés, vagy nem lehet javítani, hanem, hogy már egyre kevesebb mindenben lehet a kereket feltalálni, megváltani a világot.
Persze nem minden jó, ami régi, azt is el kell ismerni. Vannak sajnos olyan dinoszauruszok, amik mesterségesen vannak fenntartva, pl. Cobol, ami egy ultrafos valami volt mindig is, és egy nagyhatalmú speciális üzemeltetői bázis nem tudja elengedni, de ez ritkaság.
“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”
- A hozzászóláshoz be kell jelentkezni
Az írásaidból 30-as körül gondoltalak, de ezek szerint 4 évvel még nálam is idősebb vagy, úgyhogy értened kéne, amiről beszélek.
Hát... haladok a korral, nem ragadok le a múltban. :D
Pár hónapja beszélgettünk a kétezres évekről egy másik "nagy öreggel" egy meetup utáni sörözésen, az egyik igen jó harmicnas előadó hallgatta, hallgatta, majd: "basszus, én akkor még óvodás voltam", de ettől ő még jelenleg a szakmája csúcsán lévő harmincas szakember, akiből 20 év múlva vagy szintén "nagy öreg" lesz, vagy egy kiégett munnyogó balfasz a sok közül, előre nem lehet tudni.
Átláttál, megéltél annyi trendváltozást, hogy a mai hype nem kéne, hogy elvarázsoljon.
Nem varázsol el a hype, viszont nem lettem begyöpösödött, kiégett és minden újdonságra munnyogó ötvenes, mint oly sokan. Aki folyton a múltat nézi, az seggel előre megy a jövőbe.
Pont azért, amit itt utánam is írtak, hogy a 40-50-esek láttak már egy csomó hype-ot annak idején is, hogy X OS meg Y világmegváltó nyelv, módszertan majd minden problémát megold, aztán nem, csak feltalálták újra a kereket, meg utána ki is mentek a divatból.
Ha nem próbáljuk ki, sose tudjuk meg, hogy valóban jó-e vagy csak egy üres ígéret egy új eszköz, technológia vagy módszertan. Viszont érdemes objektív szempontból megnézni, de az objektivitás meg a korral valahogy elveszik és ha nem figyelsz, akkor lassan és évről-évre minden szar lesz, ami újdonság, nem tudod már objektíven megítélni és elkezded pejoratív jelzőkkel agganti az új dolgokat.
- A hozzászóláshoz be kell jelentkezni
Az ér, ha én aggatom azokra is, de a régiekre is? :D
- A hozzászóláshoz be kell jelentkezni
Ezt megnyugvással hallom :D
- A hozzászóláshoz be kell jelentkezni
Az életkorodhoz képest (sok tapasztalat után) legalább is gyanúsnak kéne lenni, hogy ha valami elég régóta van az iparban, sokan használnak, akkor sokaknak értékes és hasznos dolog lehet.
Majdnem az összes írásodból az jön le (nekem, 50), hogy rengeteget általánosítasz és ez totál nem produktív pl itt se, amikor egy konkrét technológiáról (systemd) van szó. Trendeket látni lehet, csak ott meg a kapitális hibát azzal követjük el, ha nem vesszük figyelembe a *mai* igényeket, elvárásokat és adottságokat (jóval bonyolultabb, komplexebb, rugalmasabb működés és nagyságrendekkel nagyobb számosság, terhelés, stb). Régi eszközökkel és módszertanokkal a közelébe nem tudnánk érni a mai szolgáltatási szinteknek se infra se szoftver szinten. Ezt szerintem nem érdemes azzal keverni, hogy az alapok még "tartják magukat" (mint pl a UNIX elemei, az internet vagy a szoftverfejlesztés alapjai).
Nekem személy szerint a benyomásom a systemd-vel kapcsolatban az - általánosítok egyet :D, csak benyomás, mert nekem ritkán jön szembe -, hogy sokan szívnak vele, ami szerintem ugyanarra vezethető vissza mint régen is :D, hogy rtfm gondok vannak és bonyolultabb kezelni, mert természetesen több és bonyolultabb problémát old meg, mint a korábbi megoldás. Testre szabni és saját dologgal kiegészíteni egyenesen "rémálom" lehet.
Azt a gondolatot mondjuk nem is értem, amikor valaki gyakorlatilag ki szeretné szedni egy rendszerből amikor ez annyira alap funkciókat valósít meg - ott akkor már a disztrib vagy oprendszer se stimmel valójában. :)
- A hozzászóláshoz be kell jelentkezni