Debian Bullseye Bookworm (12.5) naprakész rendszer, amelyen többek közt egy kea-dhcp4-server van. Na ezzel vannak gondok. Amikor újraindítom bármiért a gépet, a dhcp server elhasal.
jún 02 15:55:56 ..... kea-dhcp4[1779]: WARN DHCPSRV_OPEN_SOCKET_FAIL failed to open socket: the interface enp3s0 is not running
Ez ugyan csak 'warn', de ezen kéne futnia, utána nem sokkal ki is lép (az időpontot szándékosan hagytam benne, később lényeges lesz).
A kea-dhcp4-server.service file részlete:
Wants=network-online.target
After=network-online.target
Tehát akkor kéne indulni, ha már online.
A network-online.service.wants könyvtárban symlink van a networking.service NetworkManager-wait-online.service service-ekre (network-managerrel van beállítva a hálózat)
A NetworkManager-wait-online.service logja:
jún 02 15:55:47 ...... systemd[1]: Starting NetworkManager-wait-online.service - Network Manager Wait Online...
jún 02 15:55:55 ...... systemd[1]: Finished NetworkManager-wait-online.service - Network Manager Wait Online.
Ez eddig jó, megvárta a Kea, míg a network-manager végzett, és azt mondta, hogy online. Ehhez képest:
journalctl -b -0 -u NetworkManager.service
jún 02 15:55:49 ..... NetworkManager[624]: <info> [1717336549.1157] manager: (enp3s0): new Ethernet device (/org/freedesktop/NetworkManager/Devices/2)
jún 02 15:55:49 ..... NetworkManager[624]: <info> [1717336549.1206] device (enp3s0): state change: unmanaged -> unavailable (reason 'managed', sys-iface-state: 'external').....
jún 02 15:56:30 ..... NetworkManager[624]: <info> [1717336590.5688] device (enp3s0): carrier: link connected
jún 02 15:56:30 ..... NetworkManager[624]: <info> [1717336590.5700] device (enp3s0): state change: unavailable -> disconnected (reason 'carrier-changed', sys-iface-state: 'managed')
jún 02 15:56:30 ..... NetworkManager[624]: <info> [1717336590.5725] policy: auto-activating connection 'Supervisor enp3s0' (98edc68d-e0ea-3317-8a50-97a85def3b2a)
jún 02 15:56:30 ..... NetworkManager[624]: <info> [1717336590.5736] device (enp3s0): Activation: starting connection 'Supervisor enp3s0' (98edc68d-e0ea-3317-8a50-97a85def3b2a)
jún 02 15:56:30 ..... NetworkManager[624]: <info> [1717336590.5738] device (enp3s0): state change: disconnected -> prepare (reason 'none', sys-iface-state: 'managed')
jún 02 15:56:30 ..... NetworkManager[624]: <info> [1717336590.5744] manager: NetworkManager state is now CONNECTING
jún 02 15:56:30 ..... NetworkManager[624]: <info> [1717336590.5748] device (enp3s0): state change: prepare -> config (reason 'none', sys-iface-state: 'managed')
jún 02 15:56:30 ..... NetworkManager[624]: <info> [1717336590.5764] device (enp3s0): state change: config -> ip-config (reason 'none', sys-iface-state: 'managed')
jún 02 15:56:30 ..... NetworkManager[624]: <info> [1717336590.5793] policy: set 'Supervisor enp3s0' (enp3s0) as default for IPv4 routing and DNS
jún 02 15:56:30 ..... NetworkManager[624]: <info> [1717336590.5972] device (enp3s0): state change: ip-config -> ip-check (reason 'none', sys-iface-state: 'managed')
jún 02 15:56:30 ..... NetworkManager[624]: <info> [1717336590.6473] device (enp3s0): state change: ip-check -> secondaries (reason 'none', sys-iface-state: 'managed')
jún 02 15:56:30 ..... NetworkManager[624]: <info> [1717336590.6479] device (enp3s0): state change: secondaries -> activated (reason 'none', sys-iface-state: 'managed')
jún 02 15:56:30 ..... NetworkManager[624]: <info> [1717336590.6486] manager: NetworkManager state is now CONNECTED_SITE
jún 02 15:56:30 ..... NetworkManager[624]: <info> [1717336590.6493] device (enp3s0): Activation: successful, device activated.
Vagyis a networkmanager szépen készre jelenti a hálózatot, majd később be is állítja. Ez így normális? Nem gondolom, pont ezért volna a NetworkManager-wait-online.service, hogy várjon addig, míg nincs beállítva a hálózat.
Lehet ezt workaroundolni valahogy a systemd-ben, tehát hogy addig várjon egy service, amíg egy megadott interface-nek nincs rendes IP címe?
Hozzászólások
Feliratkozom.
Megoldva.
A megoldás az volt, hogy a network managerben az ethernet kapcsolatnál az ipv4.may-fail opciót no-ra kellett állítani. Így a Networkmanager-wait-online megvárja, amíg lesz szabályos ipv4 cím a hálókártyán.
JFYI az "online" fogalma elég "zavaros" ezért minden disztribúcióra vonatkozóan illetve a saját igényeknek megfelelően kell konfigurálni a feltételt. Ez lehet egy sikeres DNS feloldás, egy ping, stb. Attól függ mit gondol az "online" státuszról. (értem, hogy neked ez most elég)
https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget
Nekem itt az kellett, hogy legyen IP-je a kártyának, arra meg ez az állapot megfelelő. DNS feloldás nem kell, DNS server is van ezen a gépen :)
Lehet érdemes volna megkérdezni a dhcpd deveket, hogy nem fontolnák-e ezt meg:
/sbin/sysctl net.ipv4.ip_nonlocal_bind=1
bar a dhcp-n pont lehet nem segit, mert annak a fizikai interface is kell, nem eleg ip-re bindelnie mint pl. egy apacs vagy sshd
ja, az ip_freebind az ugyanaz, csak explicit kéred a socketre, nem kapcsolod be mindenkinek.
Koszi!
Megnezem, hogy majd az sshfs is mukodni kezd-e.
a systemd serviceben is bele van irva:
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
Szemfüles a részedről, betyáros a rendszertől...
"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."
> betyáros a rendszertől...
Egyébként mi a baj azzal, hogy egy rohadtul nem triviális kérdésre a választ arra az alrendszerre hagyjuk, aki az ide vonatkozó területet kezeli?
Egy összetett, első ránézésre intelligens rendszer használatakor az ember hajlamos feltételezni, hogy ha kezeli a függőségeket, akkor számíthat arra, hogy egy szolgáltatás csak akkor indul, amikor az előfeltételek adottak. Mindig vannak persze corner case-ek és úgy láttam, hogy te elég tudatosan göngyölted fel a problémát. Pont egy olyan ponton kerül elő egy kis kavics, amire pont nem számítanék. És néhány másodpercen múlik. Azt gondoltam, hogy a betyáros jelző jól érzékelteti a benyomásomat a problémáról és a mögötte feltárt okokról.
"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."
Persze, csak tényleg az van, hogy ez egy baromi komplex kérdés, hogy mikor ready a netwörk, szerintem teljesen rendben van, hogy ezt ráhagyjuk arra az alrendszerre, ami a netwököt kezeli. (Ugye amikor meg ezt is systemd csinálja, lásd systemd-networkd, akkor meg az a baj, hogy kisgömböc). Szerintem ez kb az, ami a jó megoldás. Az tény, hogy ez ettől még egy komplex rendszer, és tény, hogy nem triviális, hogy a az ipv4 is required for this connection pipát ha nem pipálod ki, akkor ilyen hatásai vannak, szóval lehetne jobban átlátható, de imho jó helyen van ez ott, ahol van.
Friczy mester volt :)
Én imho hamar a network manager környékére mentem volna, mert ott vannak azért összefonódások, szóval ezt már megtanultam. (pl a split dns is úgy just works, hogy az open vpn connectionnak meg van mondva, hogy csak a pusholt dolgokra használja, akkor a resolved figyelembe veszi az openvpn által letolt domaint feloldáskor)
Ha 12.5-ről van szó, az nem Bullseye (az a 11.9-nél tart jelenleg), hanem Bookworm. Mindegy, nem hibáztatlak, fütyiségek ezek az idióta kódnevek, rohadtul nem adnak hozzá semmit, csak keverésre, félrevezetésre jók.
“The world runs on Excel spreadsheets.” (Dylan Beattie)