- D1Rect: Nagy "hülyétkapokazapróktól" topik
- sziku69: Szólánc.
- MasterDeeJay: Alacsony fogyasztású házi szerver a korábbi projektekből összeépítve
- Argos: Adjátok vissza a netet! - szeretnék elaludni!
- Geri Bátyó: Megint tahó voltam – SZEMÉLYISÉGFEJLŐDÉS
- gban: Ingyen kellene, de tegnapra
- ubyegon2: Airfryer XL XXL forrólevegős sütő gyakorlati tanácsok, ötletek, receptek
- Pajac: Átlátszó fém
- Magga: PLEX: multimédia az egész lakásban
- Luck Dragon: Asszociációs játék. :)
-
LOGOUT
Mára a ProHardver!/IT.News Fórum is nagylétszámú Linuxban jártas taggal büszkélkedhet. Nehéz szinteket felállítani egy olyan rendszer ismeretében, ami annyira sokrétű, hogy teljesen szinte lehetetlen megismerni minden egyes részét. Azt azonban mindenki tudja, hogy kezdő-e vagy sem. Elsősorban nekik szólnak az alábbiak, de érdemes mindenkinek elolvasnia, mint útjelző táblát.
Új hozzászólás Aktív témák
-
bambano
titán
válasz
urandom0
#34697
üzenetére
"10 éve használok desktopon Linuxot": örülök, hogy fiatal pályakezdők is elkezdenek linuxozni
Ez egyébként valami isteni gondviselés lehet, mert nekem pont két órával ezelőtt szállt el egy gépem memória hiba miatt. Óriási csodának gondolom, hogy nem dőlt össze a komplett root fájlrendszer.
-
bambano
titán
válasz
urandom0
#34681
üzenetére
tehát neked kell egy összekonfigurált drbd meg egy komplett teszt rendszer, ahol egy ilyenre rá tudsz nézni, és megfelelő mennyiségű találgatás után esetleg lesz megoldás.
ha te kérdeznéd ugyanezt, hogy oldjam meg sysv inittel, én fejből megmondanám, hogy mit csinálj.
Hát EZ a nagy különbség.
-
bambano
titán
ha keresek valamit a logban, akkor systemd esetén journalctl-lel kilistáztatom és utána grep-pel vagy valamivel keresem, megnézem.
ha text a log, akkor a grep külön program nélkül saját maga is képes elvégezni a munkáját.erre jobb napjaimban azt mondanám, hogy fork bomba
szerk: másik hsz-edre: "Stimmel. És a journalctl nem elérhető neked, vagy mi vele a gond?" például ha egy php alkalmazásban logot kell olvasni (nekem van ilyenem), akkor text lognál simán megnyitom, beolvasom, átnézem. bináris lognál forkolni kell egy journalctl-t és úgy kell elolvasni.
szerk: egyébként egy lemezhiba esetén annak van nagyobb valószínűsége, hogy a bináris log olvasható marad, vagy annak, hogy a text?
-
urandom0
senior tag
válasz
Rhino666
#34696
üzenetére
Én meg sokszor rólatok gondolom az, hogy a Systemd utálat nagyrészt abból fakad, hogy nem akarjátok megismerni, és ragaszkodtok a régi megoldásokhoz.
10 éve használok desktopon Linuxot, előtte 3 évig használtam már szerveren is, és soha nem találkoztam az általad írtakkal. Soha nem láttam korrumpálódott journalt, soha nem okozott problémát beleolvasni, soha nem volt olyan, hogy ne lett volna hozzáférhető, és soha nem volt nehezebb archiválni.
Ha nem indult el a rendszer, bebootoltam live CD-ről, és tudtam olvasni a logokat.Egy adatbazis eseten nem szamit hogy binaris-e vagy sem, ugyanis alapvetoen...
Abból a szempontból nagyon is számít, hogy a bináris feldolgozás sokkal gyorsabb. És ha az még az oda-vissza konvertálásnak van is némi plusz erőforrásigénye, cserébe sokkal gyorsabb keresni a bináris logban, sokkal gyorsabban és egyszerűbben szűrhető, sokkal gyorsabban, és szerintem ezek sokkal gyakoribb use casek, mint az, hogy 10 év múlva is olvasni kell.
És mindemellett grepelhető is, és exportálható szöveges formátumban, ha valaki azt szeretné. Nem is értem a syslog melletti ragaszkodást, a journal kb. minden szempontból többet tud. -
válasz
urandom0
#34695
üzenetére
Akkor olvass vissza, elhangzott nehany.
De itt egy par:
- konnyebben korrumpalodik
- nehezebb beleolvasni
- indokolatlanul komplikalt
- plusz eroforrast igenyel oda-vissza konvertalni
- kritikus esetben nem hozzaferheto
- nehezebb archivalni
- stb.Az, hogy ember altal feldolgozando adatot tartalmaz, indukalja, hogy ember altal olvashato formatumban erdemes tarolni, ugyanugy ahogy a hangfajlokat sem jpg-ben es a tablazatokat sem pdf-ben taroljuk. Megtehetnenk, csak lof@sz ertelme sem volna, ugyanugy ahogy a logokat binariskent tarolni sincs.
Egy adatbazis eseten nem szamit hogy binaris-e vagy sem, ugyanis alapvetoen (normalis esetben) nem turkal benne az ember, mint mondjuk ahogy a logok kozott es ott kritikus szerepe van a gyors eleresnek, nem ugy mint a logok eseteben.
Foggal-korommel ragaszkodsz egy sz@r megoldashoz, csak mert ehhez szoktal hozza...
De ha tegyuk fel ezek nem volnanak megfelelo indokok a binary log ellen, az meg nem elegendo a letezesehez, egesz addig amig nem szolnak ervek mellette. Lehet, csak minek? Lehet szemenkent csomagolni a makot is, csak nincs ertelme.
-
urandom0
senior tag
válasz
Rhino666
#34694
üzenetére
Én pl. sosem hallottam még egy indokot a binary log ellen. Az, hogy a log nagy mennyiségű, gyorsan változó adat, amelyet célszerű indexelni és metaadatokkal ellátni, az már eleve implikálja, hogy érdemes bináris formában tárolni.
Nem véletlenül alakultak ki a bináris fájlformátumok, jpg-t sem szöveges dokumentumban tárolunk, és az adatbázisok is jellemzően binárisak. És a log sem egyéb, mint adatbázis.
Na mindegy, a lényeg, hogy mindenki megtalálhatja az a disztrót, ami számára a legszimpatikusabb. -
válasz
urandom0
#34693
üzenetére
Lehet csurni-csavarni, az elso 13 pont kozul egyik sem indokolja a binaris logot, meg csak utba sem esik. Egyenesen logikai bukfenc, hogy ezeknek a megvalositasahoz minek kellett binarissa tenni a formatumot, de ha teged ennyire nem zavar a felesleges konvertalas oda-vissza, akkor nem akarlak lebeszelni rola.
Szerintem KISS, if it ain't broke, don't fix it es don't overengineer, ezek alapjan pedig semmi letjogosultsaga nincs a binaris logoknak, tehat nem is hasznalom oket es megis valahogy kepes vagyok a letezesre ennek ellenere.
-
urandom0
senior tag
válasz
Rhino666
#34692
üzenetére
Persze, minden megoldható, ha újraírjuk, átírjuk, szabványosítjuk, gyököt vonunk belőle, deriváljuk és hozzáadjuk a jogosultságkezelést
A szabványosítás egyébként megtörtént, úgy hívják, bináris log. Itt van hozzá a leírás, itt meg a referencia implementáció.
Amiket leírtál, annak kb. a felét pont a binary log oldja meg, pl. az indexelést vagy a metaadatok hozzáfűzését. Lehet plain textet indexelni, de senki nem csinálja, főleg nem logban, ahol folyamat jönnek és jönnek az adatok, így folyamatosan újra és újra kellene indexelni az egészet.Az 1.-es pl. megoldható manuális munkával (és reménykedsz benne, hogy nem crashel tőle a program), de a journal-ban alapból ott a program PID-je.
A plain textetet is lehet szabványosítani, persze, csak nem annyira jó dolog a flat file db, mert lassú, mert az indexelhetősége közel nulla, stb.... -
válasz
urandom0
#34691
üzenetére
1. Egyszeru fajlrendszer jogosultsaggal meg lehet ugrani
2. Plain text formatumban is lehet szabvanyositani
3. TZ-t tartalmazo timestampet is lehet plain textben
4. Megint csak szabvanyositas kerdese
5. Plain text indexelheto
6. Szabvanyositas
7. Jogosultsag
8. Jogosultsag
9. Szabvanyositas
10. A rotacio megoldott problema
11. Megoldott problema
12. Megoldott problema: tar pigz
13. Megoldott problema
14. Nem igazan jut eszembe, hogy mi haszna volna binaris fajlokkal teleszemetelni a logokat, ez egy ettol teljesen fuggetlen problemanak tunik, de megadom ezt az egy pontot, csak hogy ugy tunjon hogy egyetlen egy szempontbol van ertelme a binaris logolasnak. -
urandom0
senior tag
válasz
Rhino666
#34690
üzenetére
A legtöbb pont nem értelmezhető bináris log nélkül, azaz vagy nem lehet megcsinálni szöveges loggal, vagy nem lehet normálisan megcsinálni.
Meg lehet csinálni pl. a logban mezők hozzárendelését valamilyen flat file adatbázis formátummal, mondjuk CSV-vel, az akár nyers formában is olvastható. De attól az még nem lesz indexelhető, attól még lassú lesz (ami embedded eszközökön érezhetően lassít a működésen), stb. -
válasz
urandom0
#34687
üzenetére
14 pontban ossze van foglalva hogy (szerintuk) mitol jobb a journalctl mint a syslog, nem pedig az, hogy mi haszna a binaris logoknak. Es ahogy nezem a felhozott 14 pont java is vitathato, vagy eleve nemletezo problema. Tipikusan "igeny nem volt ra, csak unalmaban hozzanyult" csak mert nem hallott meg az "if it ain't broke, don't fix it" elvrol.
De ahogy nezem tenyleg nagy vendor lock-in rajongo lehet, ha mar kepes volt google doc-kent megosztani valami szabad, fuggetlen formatum helyett (html, md, plain text).
-
urandom0
senior tag
válasz
vargalex
#34688
üzenetére
Rosszat nézel, az első 14 pontot kell nézni.
A második 14 pont nem a Syslog ellenében definiálja a Journalt, hanem azokat a követelményeket magyarázza, amiket a Journal tervezése során figyelembe vettek.
Azt nem állítja senki, hogy a második 14 pont közül a szöveges log egyet vagy többet ne tudna teljesíteni. -
vargalex
félisten
válasz
urandom0
#34687
üzenetére
A felsoroltakból a 4-es pont a kedvencem:
"Portable: journal files should be usable across the full range of Linux systems, regardless which CPU or endianess is used. Journal files generated on an embedded ARM system should be viewable on an x86 desktop, as if it had been generated locally."Mert ez a plain text logra nem igaz??? Ugyanis csak akkor lenne előny.
-
Persze, ha az onszopatas es/vagy a vendor lock-in rajongoja volnek, akkor egesz konnyeden meg tudnam oldani.
De en inkabb plain textben tarolom a logokat es azzal olvasom amivel epp kedvem tartja. Plain text olvaso 10 ev mulva is lesz, journalctl meg vagy lesz vagy nem (remelem nem), es ha lesz is, akkor vagy kepes lesz olvasni a 10 evvel azelotti logokat, vagy nem. Az biztos hogy en nem fogok izzadni, hogy 10 evvel azelotti verzioju journalctl binarist forditsak kezzel csak mert Poetteringnek anno volt egy ilyen idiota ertelmetlen agymenese, hogy legyen binaris formatumban tarolva a log (haszna semmi, de legalabb plusz potencialis hibaforras, kompatibilitasi problema stb).
Ha ennyire vagynek arra hogy egy harmadik fel dontson az EN adataim felett, akkor valoszinuleg macOS-t hasznalnek.
-
Binaris log olvasasra alkalmas programok listaja:
- journalctlPlain text log olvasasara alkalmas programok listaja:
- nano
- micro
- cat
- nl
- tail
- head
- more
- less
- vi
- vim
- mcview
- mcedit
- gedit
- kate
- notepadqq
- ...A hobbistak azt hasznaljak, ami keznel van, a kevesbe hobbistak meg azt ami leginkabb megfelelo az adott celra.
-
urandom0
senior tag
válasz
sh4d0w
#34672
üzenetére
miert kell elbaltazni valamit, ami jol mukodik?
Miért, el van baltázva? Nem logol a rendszered? Vagy nem tudod elolvasni őket?
Én elsősorban a könnyű kereshetőség, szűrhetőség miatt szeretem a bináris logot, és szerintem ez kicsit gyakoribb use case, mint az, hogy 10 év múlva is szükség lesz a logokra. De itt még van pár érv.
Ha nem systemd service, akkor se induljon el - ha mar ugyis rakkent terjedt szet a systemd.
Ha nem systemd serviceként definiálsz valamit (és nem is timer, nem mount unit), akkor
hogy várod el, hogy a systemd kezelje?semmi koze a lokalis systemdnek ahhoz, hogy a tavoli rendszeren mennyi eroforrast zabal a process
Én távoli processzről beszéltem. A távoli processzt a távoli OOM killer lelövi, ha túl sok memóriát eszik.
Egyébként az OOM killer nem systemd feature, hanem kernel feature, és kikapcsolható (ha tényleg ez lövi ki a processzt).ha a userneved szammal kezdodott, akkor root jogosultsagot kaptal
Ez ugyanaz a hiba, mint amiről korábban beszéltünk. A számmal kezdődő usernevet a Systemd invalidnak tekinti (ilyen nevű user nem létezhet a Systemd policyja szerint), ezért fallbackelt rootra. Egyébként 2017-ben lett javítva.
-
sh4d0w
félisten
Ez nem human readable?
2025-03-18 19:29:51 status triggers-pending man-db:amd64 2.11.2-22025-03-18 19:29:51 status unpacked dkms:all 3.0.10-8+deb12u12025-03-18 19:29:52 startup packages configure2025-03-18 19:29:52 configure dkms:all 3.0.10-8+deb12u1 <none>2025-03-18 19:29:52 status unpacked dkms:all 3.0.10-8+deb12u12025-03-18 19:29:52 status half-configured dkms:all 3.0.10-8+deb12u12025-03-18 19:29:52 status installed dkms:all 3.0.10-8+deb12u12025-03-18 19:29:52 trigproc man-db:amd64 2.11.2-2 <none>2025-03-18 19:29:52 status half-configured man-db:amd64 2.11.2-22025-03-18 19:29:52 status installed man-db:amd64 2.11.2-2 -
bambano
titán
válasz
urandom0
#34670
üzenetére
jaja, logszerver... múltkor is kaszálnom kellett, mert logszerverek nőttek a réten és zavarták a kilátást.
De mondok neked egy relatíve egyszerű dolgot:
debian trixie, van egy bekonfigurált drbd-m. ezt fel kell moutolni a home-ba, és ha sikerült, akkor engedni, hogy elinduljon a lightdm.ez rc.localban pár sor. lássuk a te systemd-s megoldásodat. ez egy ilyen történet, amire én gondoltam, a csomagkarbantartók meg nem. de a második fordulóra van ennél jóval cifrább is.
-
sh4d0w
félisten
válasz
Rhino666
#34669
üzenetére
Valojaban a systemd egyetlen dolgot sem csinal jol: itt tobben tobbszor is emlitettek, hogy mekkora jo feature, hogy barmibol tudsz service-t csinalni. Nos, ez teljesen nem igaz, nalam altalaban 3 alkalombol 2x nem sikerul (pedig sem hulyenek, sem tapasztalatlannak nem tartom magam) - miutan ez a kelletenel tobbszor fordult elo, igy mar nem is probalkozom vele.
-
sh4d0w
félisten
válasz
urandom0
#34670
üzenetére
"De ez nem 10 év múlva derül, hogy hoppá, vissza kéne olvasni, hogy mi volt 2015 március 18-n, hanem ezt tudja az ember. Ha pedig tudja, akkor nyilván fel is készül rá, átküldi log szerverre, amit aztán archivál."
Visszautalnek bambano mondandojara: miert kell elbaltazni valamit, ami jol mukodik?
"Biztos lehet, kérdés, hogy hogy van megoldva a tűzfal konfig betöltése. Ha az egy systemd service, és hibára fut, akkor meg lehet adni a network service-nek is, hogy ne induljon el."
Ha nem systemd service, akkor se induljon el - ha mar ugyis rakkent terjedt szet a systemd.
"Én tmuxot használok, de sosem lőtte még le a systemd egyetlen processzemet sem. Amikor mégis ilyesmi történt, az az OOM Killer okozta, de hát annak pont az a dolga, hogy lelőjje a túl sokat zabáló processzt."
Mas meg screent es igen, lelovi a tavoli processt - semmi koze a lokalis systemdnek ahhoz, hogy a tavoli rendszeren mennyi eroforrast zabal a process, lehet, hogy az a dolga (csak a teljesseg igenye nelkul: DB reorg, sha checksumok stb.).
"Itt nem tudom, mire gondolsz, én a dmidecode és a biosdecode programokat ismerem, de azoknak semmi köze a systemdhez."
https://github.com/systemd/systemd/issues/2402
Ezen felul persze azt is tudta a systemd (nem tudom, hogy ez igy van-e meg): ha a userneved szammal kezdodott, akkor root jogosultsagot kaptal, maga Poettering is kihasznalta ezt a bugot.
-
válasz
urandom0
#34670
üzenetére
Tehat a logoknak ket fontos szerepe van, az egyik a debugolas a masik pedig az archivalas. Mindketto plain text formatumban tortenik hogy ember altal olvashato legyen. A systemd pedig binaris formatumban tarolja oket, mert ____________.
a) hulye
b) igy garantalja a rendszeres korrumpalodast
c) igy plusz eroforrast kepes pazarolni
d) a fentiek mindegyike -
urandom0
senior tag
válasz
sh4d0w
#34668
üzenetére
Pl. azert akarhatsz logokat olvasni 10 ev mulva, mert torveny irja elo.
De ez nem 10 év múlva derül, hogy hoppá, vissza kéne olvasni, hogy mi volt 2015 március 18-n, hanem ezt tudja az ember. Ha pedig tudja, akkor nyilván fel is készül rá, átküldi log szerverre, amit aztán archivál.
lehetne, hogy ne huzza fel a halozatot, ha valamiert nem sikerul betolteni a tuzfal konfigot?
Biztos lehet, kérdés, hogy hogy van megoldva a tűzfal konfig betöltése. Ha az egy systemd service, és hibára fut, akkor meg lehet adni a network service-nek is, hogy ne induljon el.
Lehetne, hogy a screenben inditott tavoli processeket ne loje le?
Én tmuxot használok, de sosem lőtte még le a systemd egyetlen processzemet sem. Amikor mégis ilyesmi történt, az az OOM Killer okozta, de hát annak pont az a dolga, hogy lelőjje a túl sokat zabáló processzt.
Lehetne, hogy az alaplap EFI ertekei ne valtozokba toltodjenek be, hanem konstansokba?
Itt nem tudom, mire gondolsz, én a dmidecode és a biosdecode programokat ismerem, de azoknak semmi köze a systemdhez.
-
sh4d0w
félisten
válasz
urandom0
#34666
üzenetére
Pl. azert akarhatsz logokat olvasni 10 ev mulva, mert torveny irja elo. A text logot 10 ev mulva az akkori okoshajcsaton is el fogom tudni olvasni, a binarist meg nem, mert ahhoz kell egy futo systemd, meg az, hogy ne korruptalodjon a binarist log addig - ami nem erossege a journalnek.
De ha mar systemd: lehetne, hogy ne huzza fel a halozatot, ha valamiert nem sikerul betolteni a tuzfal konfigot? Vagy ha mar mindenaron felhuzza, akkor szoljon a sysadminnak, hogy szaros a palacsinta? Lehetne, hogy a screenben inditott tavoli processeket ne loje le? Lehetne, hogy egy printer install miatt ne baszodjon el a tuzfal konfig? Lehetne, hogy az alaplap EFI ertekei ne valtozokba toltodjenek be, hanem konstansokba?
Hja, Poettering azota elment fejlesztonek a Microsofthoz - roluk azert mult penteken feltettem a kerdet, hogy minek irnak egyaltalan programokat: a marciusi javitocsomag 57 biztonsagi hibajabol 44 magas, vagy kritikus besorolasu a CVSS 3 szerint...
szoval igen, osszenott, ami osszetartozik. -
urandom0
senior tag
válasz
bambano
#34665
üzenetére
Az svr4 init is újraindít processzeket, ehhez csak az inittabba kell egy sor. Nem rakás unit file szerteszéjjel szórva a komplett fájlrendszerben.
Nincsenek szerte szét szórva, minden egy könyvtárban van...
Elhiszem, hogy a doksiban el tudtad olvasni, hogy tud dependelni. A valóságban nem működik rendesen.
Nálam eddig mindig működött. Pont a napokban csináltam rsync-hez egy service-t, ami fájlokat szinkronizál két RPi között,
A szöveges logokat is lehet szűrni grep-pel. Nem találjuk fel újra a kereket.
Hát persze, amíg egy-egy kifejezésre akarsz szűrni, ez addig jó. De ha kicsit pontosabban akarsz szűrni, mondjuk X-Y dátumtartományon belül szeretnéd szűrni egy adott service-től érkező üzenetek közül a critical üzeneteket, de azok közül is csak azokat, amik adott usertől érkeznek, úgy, hogy szerepeljenek benne plusz adatok (pl. a teljes cmd line, a hostname, ...), az journaldctllel egy sor. Grepeld ki ugyanezt...Azokat a beállításokat, amiket a journald-nek meg lehet adni, csak bináris naplózással lehet megadni?
A beállításokat szöveges conf fájlban adjuk meg.
Van biztosíték arra, hogy azokat a bináris naplókat 10 év múlva is fogod tudni olvasni bármivel?
Miért akarnék 10 év múlva logokat olvasni? 10 év múlva jó eséllyel a mostani rendszerek fele sehol sem lesz, nem hogy a logjaikat olvasgassam.
De ha annyira fontosak a logok, be lehet állítani a journal.conf-ban, hogy továbbítsa a syslognak, vagy systemd-journal-remote-tal átkültheted log szerverre.
Egyébként a Systemd-et le fogod tudni fordítani 10 év múlva is.Az, hogy amit svr4 initben 20 másodperc alatt egy darab vi-jal elintézek, azt systemd-nél három nap guglizás után se lehessen elintézni, az nonszensz.
Pl?
-
bambano
titán
válasz
urandom0
#34662
üzenetére
Ha hibás a dns konfig, akkor hibásnak *KELL* lenni a hálózatnak, különben sosem derül ki, hogy hibás a konfig. Annak is célnak kell lenni, hogy kitakarítod a hibákat a rendszerből.
Az svr4 init is újraindít processzeket, ehhez csak az inittabba kell egy sor. Nem rakás unit file szerteszéjjel szórva a komplett fájlrendszerben.
Elhiszem, hogy a doksiban el tudtad olvasni, hogy tud dependelni. A valóságban nem működik rendesen.
A szöveges logokat is lehet szűrni grep-pel. Nem találjuk fel újra a kereket.
"biztos lehetek benne, hogy" a szolgáltatásod vagy elindul, vagy nem.
Azokat a beállításokat, amiket a journald-nek meg lehet adni, csak bináris naplózással lehet megadni? Van biztosíték arra, hogy azokat a bináris naplókat 10 év múlva is fogod tudni olvasni bármivel?
Azt akarom, hogy ha más a feladat, és svr4 initben pikk-pakk össze lehet rakni, akkor systemd-ben még kevesebb meló legyen összerakni, különben nincs okom váltani. Az, hogy amit svr4 initben 20 másodperc alatt egy darab vi-jal elintézek, azt systemd-nél három nap guglizás után se lehessen elintézni, az nonszensz.
-
vargalex
félisten
válasz
urandom0
#34662
üzenetére
Azért a network-wait-online-val kapcsolatban lenne negatív tapasztalatom. Nagyon nem úgy működik, ahogy elvárná az ember. Van saját fejlesztésünk egy ügyfélnél, hogy-hogy nem, éppen RHEL-en, ami egy Oracle szerverhez kapcsolódik. A service file-ja dependel a
network-online.target-re. Mivel az ügyfélnek van RHEL support-ja, így felvette velük a kapcsolatot. A vége az lett, hogy kezeljük az alkalmazásban... Meg is tettük.
Simán tudtuk egy netcat-el reprodukálni és prezentálni nekik. -
urandom0
senior tag
válasz
bambano
#34660
üzenetére
Ha be van állítva DNS cím, akkor nem fallbackkel, még akkor sem, ha nem elérhető a DNS szerver. Ha viszont nincs beállítva statikus DNS cím, és a kliens nem kap sehonnan sem DNS címet, akkor lép életbe a fallback DNS.
Egy processz elszállhat tőle független okokból is, viszont van értelme újraindítani a processzt az ok megszűnése után.
De én nem ezért szeretem a Systemd-t, hanem mert úgy általában lehet dependelni a szolgáltatásokra, nagyon egyszerűen. Pl. a network-wait-online-re (vagy a network-pre.targetre) dependelve biztos lehetek benne, hogy addig nem fog elinduli a service-em, amíg nincs hálózat.
És én a logolást is szeretem, nagyon könnyen lehet szűrni egy unitra, vagy adott időtartományra, stb. A journald-nak van egy csomó beállítása, meg lehet adni, hogy meddig logoljon, mennyi tárhelyet használhat maximum, és ezt megint viszonylag egyszerűen.
De ha csak arról van szó, hogy egy sima service-t kell indítani, azt is pár perc összerakni...Ha mást akarsz, mint amit a csomagkarbantartók kitaláltak, akkor nem meglepő, hogy falakba ütközöl, azért ez nem egyedi jelenség.
-
urandom0
senior tag
A Debian pl. nem is Systemd-rá állt át először, hanem azt hiszem, Upstartra. Aztán amikor más disztrók váltottak Systemdre, a Debian a következő kiadást is már azzal adta ki.
Ha jól emlékszem, volt erről szavazás Debianon belül, és akkor döntöttek a Systemd mellett.
De hogy miért döntött az összes fő disztrók a Systemd mellett, annak szerintem a legfőbb oka a praktikum, ugyanis a Red Hat adja a Linuxos fejlesztések egy nagy részét, és ha a Red Hat valamit bevezet, az rendszerint előbb-utóbb megjelenik a többi disztróban is (persze, vannak kivételek). Ugye a Red Hatnál főállású fejlesztők dolgoznak a Linuxon, a közösségi disztrók folyamatosan maintainer hiánnyal küzdenek...
Szóval így könnyebb lekövetni a változásokat. Mert pl. a Gnome is támaszkodik a Systemd-re, és ha egy disztró támogatja a Gnome-ot, akkor ez kevesebb munkát jelent neki hosszútávon, ha eleve Systemd-es. -
bambano
titán
válasz
urandom0
#34659
üzenetére
"Ez jelen pillanatban úgy működik": és itt a hangsúly a jelen pillanaton van.
Szerintem ha rossz a dns konfig, akkor működjön rosszul (vagyis ne működjön). A hiba elmaszkolása azt okozhatja, hogy a hiba oka nem kerül kijavításra.
Egyébként ezt az egész systemd alapgondolatot nem értem. Azt mondják, akik szeretik, hogy azért is jó a systemd, mert menedzseli a processzeket, újraindítja, ha elszálltak, stb. De miért is száll el egy processz, amire fontos feladatokat akartak bízni? Ha egy processz elszáll, akkor nem az a megoldás, hogy körbepakoljuk mindenféle szeméttel, ami újraindítja (és maga is bughalmaz), hanem az, hogy kijavítjuk a programot és akkor nem fog elszállni.
Egyébként amíg out of the box használom a debiant, nekem sem szokott semmi bajom lenni, még a systemd-vel sem. De abban a pillanatban, ahogy valami mást akarok, mint a csomag-karbantartók, rögtön falakba ütközöm.
-
urandom0
senior tag
válasz
bambano
#34651
üzenetére
Ismerem a nézeteid a Systemdről, és tudom, hogy ha ezer hozzászólást írnék arról, hogy szerintem miért nincs így, akkor te az 1001-ben leírnád, hogy de, így van
Én is Linux (és Windows) üzemeltetésből keresem a kenyerem, és sosem volt gondom a Systemddel.Csak ezekre válaszolok:
Aki olyan baromságot csinál, hogy ha nemlétező user alatt kellene futtatni egy programot, akkor falbackkel rootra, és azóta sem látszik, hogy javult volna a hozzáállása, azt nem engedjük be komoly rendszerbe.
Ez jelen pillanatban úgy működik, hogy ha nem létező user-t adsz meg, akkor nem indul el a service ("Failed to determine user credentials: No such process").
Lásd még fallback google dns-re.
Ez tényleg rossz lépés volt, de úgy látom, javítva lett, most már megadva FallbackDNS, csak lehetőségek vannak felsorolva:
# Some examples of DNS servers which may be used for DNS= and FallbackDNS=:
# Cloudflare: 1.1.1.1#cloudflare-dns.com 1.0.0.1#cloudflare-dns.com 2606:4700:4700::1111#cloudflare-dns.com 2606:4700:4700::1001#cloudflare-dns.com
# Google: 8.8.8.8#dns.google 8.8.4.4#dns.google 2001:4860:4860::8888#dns.google 2001:4860:4860::8844#dns.google
# Quad9: 9.9.9.9#dns.quad9.net 149.112.112.112#dns.quad9.net 2620:fe::fe#dns.quad9.net 2620:fe::9#dns.quad9.net -
Eleinte jo volt (ertsd: mert nem volt jobb) es ott ragadtak mert lassuak, szerintem ilyen egyszeru. De ennyi erovel azt is kerdezhetned hogy miert a leggyakoribb Linux distro az Ubuntu, mikozben egy otvaros takolmany az egesz. Sosem fogom megerteni hogy miert hasznalja barki onszantabol, de ettol meg annak a legnagyobb a piaci reszesedese.
-
bambano
titán
-
bambano
titán
Például a google szerverein szinte biztosan nem oob linux disztró fut. Tehát pont ők azok, akiknek teljesen mindegy, hogy mi van az átlag desktop user linuxában.
Az ibm pc azért nyert, mert az ibm hagyta, hogy belepiszkáljanak a vasba. A linux azért nyert a mininx-szel szemben, mert Linus hagyta, hogy mások is hozzájáruljanak a kernelhez. A minix egy zárt rendszer, aminek elolvashatod a forrását. Mondjuk lehet, hogy lehetne párhuzamot vonni Pöttering és AST stílusa között... lol.
Mondjuk az egy érdekesebb vita lehetne, hogy a linux miért nyert a freebsd-vel szemben is...
-
bambano
titán
válasz
urandom0
#34644
üzenetére
Az első és legfontosabb probléma a systemd-vel, hogy Pöttering elvtárs sokszor és alaposan eljátszotta a bizalmat. Aki olyan baromságot csinál, hogy ha nemlétező user alatt kellene futtatni egy programot, akkor falbackkel rootra, és azóta sem látszik, hogy javult volna a hozzáállása, azt nem engedjük be komoly rendszerbe. Lásd még fallback google dns-re. És akkor még nem beszéltünk arról, hogy pulseaudio téren is futott már ámokot az elvtárs.
A második probléma, hogy a systemd nem működik. Amennyiben olyat szeretnél vele csinálni, ami nem az alap, akkor nem működik.
Harmadik, hogy a unix az sor alapú szöveges dolgokra van optimalizálva. Az, hogy a sima txt logokról áttért binárisra, az lehet egy jó választás, ha windowsod van, de unixon nem csinálunk ilyet.
Negyedik, hogy ki a franc ez a pöttering, hogy rákényszerít engem és másokat is olyan plusz munkára, ami nem térül meg soha? Az eredeti sysv init tudott mindent, amire valóban szükség van, ha kellett syslog, ntpd, felraktad, oszt jónapot. Abnormális kiadásokra kényszerít. És ne csak arra gondolj, hogy otthon van egy linuxod, amit néha bekapcsolsz két windowsos játék között, hanem arra is, hogy vannak, akik linux üzemeltetésből keresik a kenyerüket.
Mondjuk Pöttering pont annál a redhat-nél dolgozott sokáig, akik hamisítottak már gcc-t is, mit csodálkozunk. Azóta meg összenőtt, ami összetartozik.
Tőle függetlenül én azt egy beteges dolognak gondolom, hogy egyes programozók akkor is programoznak, amikor nincs mit értelmesen programozni. Tölthetnék hibakereséssel is az idejüket, csak az büdös.
KISS: Keep it stupid and simple. Ami nem ilyen, az nem unix. Csináljon csilivili processz managementet windowsra, az oda való, minket (pláne a mi munkaeszközeinket) meg hagyjon békén.
-
urandom0
senior tag
válasz
Rhino666
#34647
üzenetére
Akkor lenne monolitikus, ha egy bináris lenne az egész, vagy több bináris, de annyira összehegesztve, hogy egyik nélkül nem működne a másik.
Nem tudom, mit jelent az, hogy minden átfut rajta. De simán lehet olyan Systemd buildet csinálni, ahol csak a core van, semmi más. -
válasz
ViZion
#34640
üzenetére
Semmi, csak csomoan nem vettek eszre, hogy a Linuxot 99%-ban nem ugy hasznaljak manapsag, hogy 1-10 gepet menedzselgetnek kiszakadt zokniban+szandalban, hanem mobilok es szervere szazmillioira teritik, es azok a cegek, akik ezeket a szazmillios disztrokat csinaljak, megfelelonek tartjak a systemd-t, sot, azt tartjak a jelenleg legmegfelelobbnek. Nyilvan lehet hulyenek nezni a Google, Redhat, Microsoft, Amazon Linux-mernokeit, de nem veletlenul hasznaljak.
Egyekbent pont ugyanugy nyer a systemd, mint ahogy a Linux nyert a Minix ellen. A Minix sokkal szebb architektura (mikrokernel, stb.), de a Linuxot sokkal gyorsabban adoptalta a vilag. A systemd valoban nem koveti a klasszikus 'apro toolok egyuttese'-jellegu *nix filozofiat, de a Linux-fele monolit kernelnel is sokkal kozelebb volt az Unix-filozofiahoz a Minix.
Szerintem
no offense -
-
urandom0
senior tag
válasz
Rhino666
#34642
üzenetére
- ebbol kifolyolag tulsagosan osszetett, bloatware
- ebbol kifolyolag tele van biztonsagi resekkel
- ebbol kifolyolag mesterseges fuggosegeket general
Ez nem igaz, a systemd moduláris. Van az init része, a service része, meg a journald, ez a core, de ezek is el vannak osztva több, különböző binárisra (és nem is kötelező mindegyiket futtatni). Minden más része opcionális.
De alapvetően az egyes szolgáltatásokat valakinek el kell látnia, teljesen mindegy, hogy azt most a független X bináris látja el, vagy a Systemd projektből jövő Y bináris. Semmivel nem vagy előrébb, ha a systemd-networkd helyett a dhcpcd fut, ha udev helyett eudev fut, ha systemd-journald helyett syslog fut...- azt hazudja hogy ujraindult a service, mikor nem is
Sosem találkoztam ilyennel. A journal corupptiont is csak hallomásból ismerem, de ahogy utána olvastam, sok esetben kiderült, hogy fájlrendszer hiba, vagy lemez hiba okozta.Szerintem a Systemd ellenességnek nincs értelme, már csak azért sem, mert egy csomó pluszt nyújt a Systemd. Szedett-vetett init scriptek helyett egységes, normális (függőségkezelt) service unitok, szűrhető, kereshető, jól használható log, stb.
A UNIX filozófia meg már az X-nél megbukott.
-
válasz
ViZion
#34640
üzenetére
- szembekopi a Unix filozofiat, es mindent is csinal
- ebbol kifolyolag tulsagosan osszetett, bloatware
- ebbol kifolyolag tele van biztonsagi resekkel
- ebbol kifolyolag mesterseges fuggosegeket general
- bun lassu (viszonyitasi alap nelkul nehez erzekelni)
- azt hazudja hogy ujraindult a service, mikor nem is
- gyakori log corruption
- RedHat hozadek, pfujj
- stb. -
.-..-.
tag
Sziasztok.
Volna egy script-em, amit login után (GDM), a desktop (Arch,Gnome,Xorg) megjelenését követően 5mp múlva szeretnék indítani és ~5mp-ig fut. A script-et root-ként kell futtatni.
Mi volna erre megfelelő megoldás?
Valami systemd-service amit esetleg beállthatnék az xorg indulására?
Próbáltam a GDM PostLogin és PreSession megoldásokat, de ezek várnak a visszakapott értékre (0) és ~10mp-ig megakasztják a login folyamatot. -
válasz
Vasti74
#34635
üzenetére
Ha naprakész distrot akarsz, akkor nem értem miért vagy megravadva a Debiannál, az a szöges ellentéte a naprakészségnek. Az Arch naprakész, de bleeding edge, ráadásul systemd-s. Már egyszer javasoltam fentebb, a naprakészség és stabilitás tökéletes egyensúlyában a Void Linux-ot találtam (bónusz, hogy nincs systemd), egy év distrohopping után végre le tudtam vele telepedni. Egy próbát megét, ha túl tudsz lendülni a kézi telepítésen, akkor meghálálja.
-
Vasti74
senior tag
Eléggé kicsi a valószínűsége... Az előző gépem (Fujitsu D738, i5 8400) évekig tökéletesen működött Mint Cinnamon-al, a 4k monitor megvétele után is, csak ott vacak a skálázás - váltottam Fedora Plasma-ra - jöttek a hibák. Pár hete megvettem ezt a Lenovo M75-öt Ryzen 5 4650G procival - pont ugyanazokat a hibákat produkálja.
-
CPT.Pirk
Jómunkásember
válasz
Vasti74
#34630
üzenetére
Azt hiszem annyi bajod volt az Endeavourrel, hogy abban a telepítőben még megvolt a python-future csomag, ami már nem Python3 kompatibilis és fent sem kellene lennie a gépen. Ettől meg függőségi probléma miatt megakad a rendszerfrissítés amíg ezt a csomagot nem törölted le. Azóta ők is adtak ki új telepítőt.
Hogy ez konkrétan kinek volt a hibája azt nem tudom, a python világa nekem egy hatalmas katyvasz, de valszeg a többi arch környéki disztrón is találkoztál volna ezzel ott és akkor.
-
Vasti74
senior tag
válasz
salaud
#34622
üzenetére
Hát, majd ha lesz idegrendszerem hozzá, akkor dugok egy másik SSD-t a gépbe, és telepítek valami mást. De emlékeim szerint amiket próbáltam (Neon, openSUSE) pont ugyanezeket a hülyeségeket produkálták az Intel-es gépemen, ezen az AMD-n meg már csak Fedora-t próbáltam... Az Endeavour-tól meg valamiért rögtön agyhúgykövet kaptam, de lehet, hogy csak egy rossz pillanatában csíptem el a rendszert?! Újra ki kellene próbálnom ;-) A baj az, hogy már totál nincs kedvem új rendszerrel ismerkedni, csak használnám a gépet: már a Mint - Fedora is megviselt (csomagkezelés) , pedig tudtommal még a dnf hasonít a legjobban az apt-re.
Igazából ellennék ezzel a Fedora-val, csak zavarják a szememet pl. a képernyőn villogó csíkok néha csak úgy maguktól, de pl. az asztalon egy ikont húzogatva 100%-ban reprodukálható a dolog. -
urandom0
senior tag
válasz
Rhino666
#34625
üzenetére
Én sem azt mondtam, hogy mindenkinek vannak
De Vasti végigpróbált már ki tudja hány disztrót, több géppel is, és mindegyiknél előjöttek a problémái. Csak bizonyos hardverek, szoftverek és beállítások kombinációja esetén állnak fenn ezek a problémák.
A VRR állapota jelenleg:
Ha te nem esel bele ebbe a körbe, az tök jó, de sokan igen.A HRD monitor támogatás pedig így néz ki:
- KDE Plasma 6.0 introduced experimental HDR support for Wayland session.
- DRM clients can directly pass HDR metadata, but this is not available from regular userspace clients, only specialized software can use it.
- COSMIC developers have promised HDR support in the initial stable release.
- Hyprland introduced HDR support since #8715.
- Wlroots, "Add HDR signalling" MR.
- GNOME 48-beta introduces HDR support and toggle under Wayland.
Ettől függetlenül persze meg lehet próbálni a Voidot, hátha patcheltek benne valamit, ami megoldja a problémákat.
-
urandom0
senior tag
válasz
Rhino666
#34623
üzenetére
Ezek architekturális gondok, nem azért vannak, mert egy-egy disztróban gond van a csomaggal, hanem mert a desktop Linux, szépen kifejezve, kissé le van maradva 4K támogatásban (és VRR-ben is, mint ahogy HDR-ben is).
A Void egyébként nem rossz, én régebben használgattam, nem volt vele gondom. Mondjuk az már tényleg rég volt, 2017 környékén.
-
salaud
aktív tag
-
ViZion
félisten
Sziasztok!
Samba kérdés... de most teljesen összezavartam magam... asszem 
Van 3 user: u1, u2, u3, user group-ban.
Van a NAS, azon belül mappák (meglepő
).
U1+U2 mindent ír/olvas, u3 csak egy mappát ír/olvas, többire elvileg nézegetés OK.[nas]comment = NASpublic = Yespath = /mnt/nasbrowseable = Yesread only = Noguest ok = Nocreate mask = 777directory mask = 777recycle = Yesforce group = usersvalid users = @userswrite list = u1,u2Itt a 777 mask mit okoz u3-nál? (Tudom, teszteljem, de nem akarnék átlogolni, lehet csak vmit benézek). Tudja majd írni? Mert nem kellene. Igazán olvasnia sem...
de arra nincs ötletem.Ez meg a sub az u3-nak:
[film]public = Yespath = /mnt/nas/Filmbrowseable = noread only = Nocreate mask = 774valid users = @users
Köszönöm, ha ránéztek!
-
Vasti74
senior tag
válasz
salaud
#34618
üzenetére
Nálam a 4k monitor és a nem egész számra skálázás (Fractional Scaling) hozta a problémákat... Ezért váltottam először a szeretett ;-) Mint Cinnamon-ról valami friss Plasma-ra (pár disztribúció kipróbálása után lett a Fedora 41) , aztán meg cseréltem gépet, aztán meg törődtem bele, hogy ez ilyen ;-)
-
-
vargalex
félisten
Biztos, hogy nincs semmi külső hivatkozása? Esetleg nézd meg ilyenkor böngészőben a network fület, hátha igaza van bambanonek és valamit nem tud letölteni, ami kellene ehhez a lejátszáshoz is.
Nálam Arch Linux, Wayland, Gnome, nincs probléma...Szerk.: Örülök, hogy közben megoldódott. (Nálam fenn van a
pipewire-pulsecsomag,pulseaudiomár régen nincs..) -
Lenry
félisten
közben az Arch fórumon befutott ez a javaslat, és ez nyert.
nem világos, hogy mi köze a két dolognak egymáshoz, de megjavult.azért köszi a tippeket
-
Lenry
félisten
válasz
CPT.Pirk
#34603
üzenetére
[lenry@Echo-Three ~]$ vainfo
Trying display: wayland
vainfo: VA-API version: 1.22 (libva 2.22.0)
vainfo: Driver version: Intel iHD driver for Intel(R) Gen Graphics - 25.1.3 ()
vainfo: Supported profile and entrypoints
VAProfileNone : VAEntrypointVideoProc
VAProfileNone : VAEntrypointStats
VAProfileMPEG2Simple : VAEntrypointVLD
VAProfileMPEG2Simple : VAEntrypointEncSlice
VAProfileMPEG2Main : VAEntrypointVLD
VAProfileMPEG2Main : VAEntrypointEncSlice
VAProfileH264Main : VAEntrypointVLD
VAProfileH264Main : VAEntrypointEncSlice
VAProfileH264Main : VAEntrypointFEI
VAProfileH264Main : VAEntrypointEncSliceLP
VAProfileH264High : VAEntrypointVLD
VAProfileH264High : VAEntrypointEncSlice
VAProfileH264High : VAEntrypointFEI
VAProfileH264High : VAEntrypointEncSliceLP
VAProfileVC1Simple : VAEntrypointVLD
VAProfileVC1Main : VAEntrypointVLD
VAProfileVC1Advanced : VAEntrypointVLD
VAProfileJPEGBaseline : VAEntrypointVLD
VAProfileJPEGBaseline : VAEntrypointEncPicture
VAProfileH264ConstrainedBaseline: VAEntrypointVLD
VAProfileH264ConstrainedBaseline: VAEntrypointEncSlice
VAProfileH264ConstrainedBaseline: VAEntrypointFEI
VAProfileH264ConstrainedBaseline: VAEntrypointEncSliceLP
VAProfileVP8Version0_3 : VAEntrypointVLD
VAProfileVP8Version0_3 : VAEntrypointEncSlice
VAProfileHEVCMain : VAEntrypointVLD
VAProfileHEVCMain : VAEntrypointEncSlice
VAProfileHEVCMain : VAEntrypointFEI
VAProfileHEVCMain10 : VAEntrypointVLD
VAProfileHEVCMain10 : VAEntrypointEncSlice
VAProfileVP9Profile0 : VAEntrypointVLD
VAProfileVP9Profile2 : VAEntrypointVLD -
-
Vasti74
senior tag
Tudom, hogy ez rajtad nem segít, de nálam a Fedora 41 Plasma is ezt csinálja (Firefox és Chrome is) , de szerencsére nem mindig. Úgy kb. 50 "beletekerésből" 1x. Már kétféle vasam volt (az i5-8400 + IGP gépet azért cseréltem Ryzen 5 4650G + IGP masinára, hátha a sokkal jobb integrált grafika elvileg jobb támogatottsággal megoldja a problémáimat, de sajnos nem...
Én már nem is keresem az okát, mert a keresgéléseim alapján ez ilyen.
Már elavult, vagy még nem kész technológiák vacak hardvertámogatással, ezt kínálja jelenleg a linux desktop, lehet választani ;-)
De sajnos még mindig ez a legjobb alternatíva (számomra) , úgyhogy egyszerűen nem rántom fel magam, amikor nem megy a videó, vagy csíkok vannak a képernyőn, vagy vastag villogó kerete van az ablakoknak, stb. (tuti nem hardveres hiba, mert a két totál különböző gépem is pontosan ugyanúgy, ugyanazokat a hülyeségeket produkálta)
A Plasma szerintem elmebeteg és alig használható alapértelmezett alkalmazásai (Mint MATE és Cinnamon után) szintén nem tudnak már felbosszantani ;-)
szoval igen, osszenott, ami osszetartozik.
). 
de arra nincs ötletem.
Új hozzászólás Aktív témák
Hirdetés
- Nők, nőügyek (18+)
- Microsoft Excel topic
- PlayStation 5
- Yettel topik
- Kerékpárosok, bringások ide!
- Fujifilm X
- Milyen asztali (teljes vagy fél-) gépet vegyek?
- Xbox Series X|S
- Folyószámla, bankszámla, bankváltás, külföldi kártyahasználat
- Kerti grill és bográcsozó házilag (BBQ, tervek, ötletek, receptek)
- További aktív témák...
- Kaspersky, BitDefender, Avast és egyéb vírusírtó licencek a legolcsóbban, egyenesen a gyártóktól!
- Jogtiszta Windows - Office & Vírusirtó licencek- Azonnal - Számlával - Garanciával - Nint.hu
- PC Game Pass előfizetés
- Játékkulcsok a legjobb áron: Steam
- Windows 10 11 Pro Office 19 21 Pro Plus Retail kulcs 1 PC Mac AKCIÓ! Automatikus 0-24
- 35" ASUS ROG Swift PG35VQ curved GAMER monitor
- BESZÁMÍTÁS! ASROCK B550M R5 5600X 32GB DDR4 1TB SSD RTX 3060 12GB Zalman N5 MF Be Quiet 650W
- AKCIÓ! Intel Core i7 7700K 4 mag 8 szál processzor garanciával hibátlan működéssel
- Új Samsung 15 GalaxyBook 3 FHD IPS i5-1335U 4.6Ghz 10mag 16GB 512GB SSD Intel Iris XE Win11 Garancia
- Bomba ár! Dell Latitude 7390 2in1 - i7-8G I 16GB I 256SSD I 13,3"FHD Touch I HDMI I Cam I W11 I Gar
Állásajánlatok
Cég: FOTC
Város: Budapest