Udv!
A privoxym megkergult; systemctl enable privoxy.service es systemctl start privoxy.service parancsok ellenere nem indul a rendszerrel. Utolagosan ki kell adni ujra az utobbi parancsot.
A var/log/privoxy/logfile az alabbit hibauzenetet dobja: 7f58c9213700 Fatal error: can't bind to 192.168.1.1xx:8118: Cannot assign requested address.
Probaltam ugy is, hogy kitoroltem a symlinket, majd ujra keszitettem. Nem mukodik, csak utolag, manualisan.
Valaki talalkozott mar ezzel a problemaval?
- 2236 megtekintés
Hozzászólások
Mik a függőségei? A Wants/After közé vedd fel a network-online target-et.
Szerk: Részletesebben lásd http://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/
Szerk II: Alternatíva, állítsd át, hogy 0.0.0.0-ra vagy csak a 127.0.0.1-re figyeljen.
BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)
- A hozzászóláshoz be kell jelentkezni
Koszonom SzBlackY, az elso variacio segitett. :)
- A hozzászóláshoz be kell jelentkezni
Klasszikus systemd design bug.
A systemd nem várja meg, hogy a dhcpcd tényleg felvegye az IP címet, hanem egy kicsit korábban ráindítja a network.target-re függő service-eket.
Sajnos a helyzet meglehetősen zavaros, itt lehet elolvasni, ahogy megpróbálják kimosdatni a bugot feature-nek: http://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/
Potenciális megoldás a network.target helyett network-online.target használata, de tapasztalatom szerint ez sem 100%-osan megbízható.
---
Régóta vágyok én, az androidok mezonkincsére már!
- A hozzászóláshoz be kell jelentkezni
Mert miért annyira egyértelmű, hogy bootkor rendelkezésre fog állni a hálózat?
BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)
- A hozzászóláshoz be kell jelentkezni
Nem egyértelmű, de szerintem ilyet nem is mondtam. Viszont a network.target-nek mégis mi értelme van a jelenlegi formájában? Arról nem beszélve, hogy pl RHEL is tele van gyárilag network.target-re függő service-ekkel, amiknek - legalábbis a linkelt magyarázat szerint - valójában a network-online.targetre kéne függeniük.
És ez utóbbi sem működik jól, ha nincs bekapcsolva network-manager.
Magyarán sajnos fokozatosan építik ki a kötelező függőséget erre a komponensre is. Szerveren kész öröm egy kicsit is komolyabb vlan-os vagy bonding esetleg bridge-es konfignál, hogy rá vagy kényszerítve network manager használatára.
---
Régóta vágyok én, az androidok mezonkincsére már!
- A hozzászóláshoz be kell jelentkezni
Nem egyértelmű, de szerintem ilyet nem is mondtam.
Egyértelműen bug-nak állítottad be, holott nem feltétlenül az
Viszont a network.target-nek mégis mi értelme van a jelenlegi formájában? Arról nem beszélve, hogy pl RHEL is tele van gyárilag network.target-re függő service-ekkel, amiknek - legalábbis a linkelt magyarázat szerint - valójában a network-online.targetre kéne függeniük.
A network.target-re a hálózati stack már készen áll - vagyis mondjuk egy 0.0.0.0-ra már tudsz bindolni.
Van olyan service, ami kifejezetten egy interface-en hallgatózna a gyári konfig szerint?
És ez utóbbi sem működik jól, ha nincs bekapcsolva network-manager.
A NetworkManager-en túl is vannak hálózat menedzserek, pl. a wicked is rántja magával a network-online-t.
De nézzük a másik irányból: ha a teljes és kizárólagos network kezelést megtartanák maguknak (így értelmezhető lenne a network.target), akkor meg az lenne, hogy a systemd már megint benyelt valami kötelező függőséget. Így viszont megmaradt a választási lehetőség, ha akarod csinálhatsz egy saját service unit-ot, amiben kézzel felkonfolod az interfészeket, ha akarod belősz egy wicked-et vagy NM-t, a lényeg, hogy utána elindítsd a network-online.target-et.
BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)
- A hozzászóláshoz be kell jelentkezni
Azért tettem így, mert emlékeim szerint ez egy bugra készült utólagos hack.
És úgy tűnik valóban, a history szerint 2013 májusában lett bevezetve, különösebb changelogban említés nélkül.
Van olyan service, ami kifejezetten egy interface-en hallgatózna a gyári konfig szerint?
Ez valóban nem jellemző, bár én akarhatok ilyet konfigolni és nem nyilvánvaló, hogy emiatt a service fájlokat is kell bántani. Ellenben kifele irányuló kapcsolatot nyitni akaró service azért előfordul. Esetek többségében ez csak logszemeteléssel és retry-olással jár, de akkor sem kellemes.
Az ok egyébként szerintem annyi, hogy sok esetben a package maintainerek egyszerűen nem húzták utána a service-eket a változásnak.
---
Régóta vágyok én, az androidok mezonkincsére már!
- A hozzászóláshoz be kell jelentkezni
Köszi a hasznos linket!
"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."
- A hozzászóláshoz be kell jelentkezni