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?
- 650 megtekintés
Hozzászólások
Feliratkozom.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
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 :)
- A hozzászóláshoz be kell jelentkezni
jún 02 15:55:56 ..... kea-dhcp4[1779]: WARN DHCPSRV_OPEN_SOCKET_FAIL failed to open socket: the interface enp3s0 is not running
Lehet érdemes volna megkérdezni a dhcpd deveket, hogy nem fontolnák-e ezt meg:
If you are a developer, instead of wondering what to do about
network.target, please just fix your program to be friendly to dynamically changing network configuration
- If you write a server: if you want to listen on other, explicitly configured addresses, consider using the IP_FREEBIND sockopt functionality of the Linux kernel. This allows your code to bind to an address even if it is not actually (yet or ever) configured locally. This also makes your code robust towards network configuration changes.
- A hozzászóláshoz be kell jelentkezni
/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
- A hozzászóláshoz be kell jelentkezni
ja, az ip_freebind az ugyanaz, csak explicit kéred a socketre, nem kapcsolod be mindenkinek.
- A hozzászóláshoz be kell jelentkezni
Koszi!
Megnezem, hogy majd az sshfs is mukodni kezd-e.
- A hozzászóláshoz be kell jelentkezni
a systemd serviceben is bele van irva:
# `nm-online -s` waits until the point when NetworkManager logs
# "startup complete". That is when startup actions are settled and
# devices and profiles reached a conclusive activated or deactivated
# state. It depends on which profiles are configured to autoconnect and
# also depends on profile settings like ipv4.may-fail/ipv6.may-fail,
# which affect when a profile is considered fully activated.
# Check NetworkManager logs to find out why wait-online takes a certain
# time.
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
- A hozzászóláshoz be kell jelentkezni
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."
- A hozzászóláshoz be kell jelentkezni
> 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?
- A hozzászóláshoz be kell jelentkezni
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."
- A hozzászóláshoz be kell jelentkezni
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
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.
. Mindig vannak persze corner case-ek és úgy láttam, hogy te elég tudatosan göngyölted fel a problémát.
Friczy mester volt :)
Pont egy olyan ponton kerül elő egy kis kavics, amire pont nem számítanék.
É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)
- A hozzászóláshoz be kell jelentkezni
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)
- A hozzászóláshoz be kell jelentkezni