Was this after a reboot or Kea just suddenly stopped responding during normal operation?
Was there nothing in logs? 1) perhaps consider some retry options: https://kea.readthedocs.io/en/kea-2.2.0/arm/dhcp4-srv.html#interface-configuration "service-sockets-max-retries” and “service-sockets-retry-wait-time”. These settings cause kea to not immediately give up in the event the interfaces aren’t available when it starts. 2) If there was nothing in logs, you may need to consider setting up additional loggers and/or turning up severity. The chart here: https://kea.readthedocs.io/en/kea-2.2.0/arm/logging.html?highlight=logging#id3 shows a list of available loggers and what they log. You may need to look at the system logs if it isn’t getting far enough to read your loggers statement. I personally like to set up a separate file for each logger name so that I can control log severity and look at things individually. Example (not exhaustive): "loggers": [ { "name": "kea-dhcp4", "severity": "INFO", "output_options": [ { "output": "/usr/local/var/log/kea-dhcp4.log", "maxver": 10, "flush": false } ] }, { "name": "kea-dhcp4.packets", "severity": "DEBUG", "debuglevel": 98, "output_options": [ { "output": "/usr/local/var/log/kea-dhcp4-packets.log", "maxver": 10, "flush": false } ] }, { "name": "kea-dhcp4.alloc-engine", "severity": "INFO", "output_options": [ { "output": "/usr/local/var/log/kea-dhcp4-alloc-engine.log", "maxver": 10, "flush": false } ] }, 3) you might change “Wants=“ to “Requires=“ as apparently “Wants=“ will let the kea service still start even if the network-online.target hasn’t properly started. Though you might be better served by #1 above. > On Jan 3, 2023, at 3:20 AM, Stefan G. Weichinger <[email protected]> wrote: > > Am 27.12.22 um 12:46 schrieb Darren Ankney: > >> In any case, I’d be concerned why it was running but not answering requests >> more-so than I would be about how to monitor it using actual DHCP. I >> vaguely remember having some trouble with Kea and systemd startup ordering >> (ie: it started up before the server’s IP was on the interface). Setting >> After=network.target took care of it. > > We saw the behavior again yesterday: no DHCP leases after a reboot until we > restarted kea. > > In the service file there are these lines: > > Wants=network-online.target > After=network-online.target > After=time-sync.target > > https://systemd.io/NETWORK_ONLINE/ gives some information about these targets > ... "network-online.target" should fit better .. but doesn't seem to be > enough. > > We use raw sockets for kea, but the server listens on multiple > vlan-interfaces: > > { > "Dhcp4": { > "interfaces-config": { > "interfaces": [ "enp0s31f6", "enp0s31f6.101", > "enp0s31f6.102", "enp0s31f6.103", "enp0s31f6.200" ], > "dhcp-socket-type": "raw" > }, > > > -- > ISC funds the development of this software with paid support subscriptions. > Contact us at https://www.isc.org/contact/ for more information. > > To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users. > > Kea-users mailing list > [email protected] > https://lists.isc.org/mailman/listinfo/kea-users
-- ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users. Kea-users mailing list [email protected] https://lists.isc.org/mailman/listinfo/kea-users
