Kea issueshttps://gitlab.isc.org/isc-projects/kea/-/issues2023-09-06T15:30:21Zhttps://gitlab.isc.org/isc-projects/kea/-/issues/3036Error while processing command 'config-set': invalid thread pool state change...2023-09-06T15:30:21ZSandeep GagalapallyError while processing command 'config-set': invalid thread pool state change to paused performed by worker threadHello,
I am running into this error when I try to do a `config-reload` of Kea DHCP via Management API.
I don't have issues when I issue `config-get `
Error: invalid thread pool state change to paused performed by worker thread
I hav...Hello,
I am running into this error when I try to do a `config-reload` of Kea DHCP via Management API.
I don't have issues when I issue `config-get `
Error: invalid thread pool state change to paused performed by worker thread
I have this payload in the body
```
{
"command": "config-reload"
}
```
Thank You,
Sandeephttps://gitlab.isc.org/isc-projects/kea/-/issues/2931Host commands fetching hosts by IP address from the backends return partial data2023-07-17T13:58:20ZMarcin SiodelskiHost commands fetching hosts by IP address from the backends return partial dataSuppose you have a host reservation that includes IPv6 addresses, prefixes and DHCP options. Now, if you send a command to fetch the host reservation by one of the IPv6 addresses, you'll get the host reservation with this IPv6 address (l...Suppose you have a host reservation that includes IPv6 addresses, prefixes and DHCP options. Now, if you send a command to fetch the host reservation by one of the IPv6 addresses, you'll get the host reservation with this IPv6 address (lacking other IPv6 addresses), without the prefixes and probably with only one of the options.
The reason for it is the invalid query that performs a simple inner join and filters by the IPv6 address. The other addresses and prefixes are ignored (filtered out) because they don't match the specified address. It seems that the correct query should run a sub-query selecting the host-id and then the main query that filters the host by this id.
The original issue was described here: https://gitlab.isc.org/isc-projects/kea/-/issues/2881#note_380311kea2.4.0Marcin SiodelskiMarcin Siodelskihttps://gitlab.isc.org/isc-projects/kea/-/issues/2883get lease count per pool follow-up2023-07-17T13:58:20ZRazvan Becheriuget lease count per pool follow-upThe following discussion from !1971 should be addressed:
- [ ] @andrei started a [discussion](https://gitlab.isc.org/isc-projects/kea/-/merge_requests/1971#note_376723):
> * [ ] Pool stats documentation
> * [ ] Pool stats unit...The following discussion from !1971 should be addressed:
- [ ] @andrei started a [discussion](https://gitlab.isc.org/isc-projects/kea/-/merge_requests/1971#note_376723):
> * [ ] Pool stats documentation
> * [ ] Pool stats unit tests in `src/lib/dhcpsrv/tests/cfgmgr_unittest.cc`
> * [ ] Pool stats unit tests in `src/lib/dhcpsrv/tests/generic_lease_mgr_unittest.cc`kea2.4.0Razvan BecheriuRazvan Becheriuhttps://gitlab.isc.org/isc-projects/kea/-/issues/2725lease prefix-len is not checked in lease commands for PD type2023-07-17T13:58:20ZRazvan Becheriulease prefix-len is not checked in lease commands for PD typethe following UT which passes, is using a wrong prefix-length for the prefix (type PD):
```
txt =
"{\n"
" \"command\": \"lease6-add\",\n"
" \"arguments\": {"
" \"subnet-id\": 66,\n"
...the following UT which passes, is using a wrong prefix-length for the prefix (type PD):
```
txt =
"{\n"
" \"command\": \"lease6-add\",\n"
" \"arguments\": {"
" \"subnet-id\": 66,\n"
" \"ip-address\": \"2001:db8:1::1\",\n"
" \"prefix-len\": 48,\n"
" \"type\": \"IA_PD\",\n"
" \"duid\": \"1a:1b:1c:1d:1e:1f\",\n"
" \"iaid\": 1234,\n"
" \"state\": 1"
" }\n"
"}";
```
clearly a check on the prefix length is missing from the code in lease commandskea2.4.0Razvan BecheriuRazvan Becheriuhttps://gitlab.isc.org/isc-projects/kea/-/issues/2707ability to detect Kea config changes (config-hash-get)2023-07-17T13:58:20ZTomek Mrugalskiability to detect Kea config changes (config-hash-get)There was a [discussion in Porto](https://pad.isc.org/p/porto2022-kea-features-for-stork#L19) about detecting out of bounds configuration changes in Kea. The overall idea is that Stork should be able to detect somewhat easily if Kea's co...There was a [discussion in Porto](https://pad.isc.org/p/porto2022-kea-features-for-stork#L19) about detecting out of bounds configuration changes in Kea. The overall idea is that Stork should be able to detect somewhat easily if Kea's config has changed, e.g. by sysadmin or some external tool.
Couple ideas were discussed:
- storing timestamp of last modification
- using hash
- using monotonic counter
- using journal file or auditlog
The overall idea is that Stork (and other monitoring tools) should be able to reasonably easily answer the question whether configuration was modified or not. It is essential the question/answer should be relatively low cost as Stork and other monitoring tools tend to look at Kea's config frequently (e.g. every 15 seconds) and the config changes are typically rare events.
This requires a short ~design.kea2.4.0Tomek MrugalskiTomek Mrugalskihttps://gitlab.isc.org/isc-projects/kea/-/issues/2631Modification of handling of global reservations with IP addresses set2023-07-17T13:58:22ZAlan CleggModification of handling of global reservations with IP addresses setCustomer request, ref: https://support.isc.org/Ticket/Display.html?id=21365
NOTE: Support ticket has patches that have been reviewed by Thomas and Francis and are not seen as appropriate. It would appear that the customers need is rea...Customer request, ref: https://support.isc.org/Ticket/Display.html?id=21365
NOTE: Support ticket has patches that have been reviewed by Thomas and Francis and are not seen as appropriate. It would appear that the customers need is real and that we should determine a good course forward.
-----------------------------
Ticket narrative provided below:
I would like to put in a feature request to modify the handling of global reservations with IP addresses set.
## Background ##
I'd like to detail some of our use case and the behaviors we have had to work around in our Kea implementation. We have created a self-service portal for users to register their devices to access the network. In the general case, this consists of a user giving us a MAC address and an FQDN for us to create a host reservation with, but we do allow IT administrators to reserve IP addresses as well. Even when a user requests a certain IP address, we do not necessarily restrict them from only using that network; i.e. they should be able to get a valid IP address in any network (with DDNS determined by the subnet they land in).
A few behaviors we've ran into using global host reservations:
1) Global reservations with IP addresses do no bounds checking on if the IP address is correct for a subnet.
a) If a device requests an address from a shared-network that does not contain its IP address, it will receive an address which cannot be used
b) If a device requests an address from a shared-network that does contain its IP address, but it's IP address is not a part of the subnet with the lowest ID, it will receive the correct address but incorrect options (e.g. routers).
2) Updated reservation MAC addresses may create conflicts when a lease with the old MAC address still exists (we use `match-client-id: false`)
3) I suspect that updated reservation FQDNs do not reflect when a client lease is updated, but have not verified
We have worked around issues 1b, 2, and 3 by modifying leases through the API via the self-service portal. On every create of update of a device with an IP reservation in our self-service portal, we ensure that the hostname, MAC address, and subnet-id on the lease(s) match what we expect. (1a) is still an issue for us and requires manual intervention to either move the device into the shared-network where it should exist, or change the host reservation to be in the shared-network where the device currently resides.
I understand there is a workaround: create two reservations (one global without an IP address and one inside the subnet with an IP address). This increases our complexity by adding another data store to keep in sync, and I believe could end up reducing performance due to more host lookups. It's my opinion that the current global reservation behavior is a footgun which can be easily avoided, and the requested behavior is more in line with what users of ISC DHCPd would expect.
## Feature Request ##
Kea should only hand out feasible addresses to clients and correctly match leases to subnets for global reservations with IP addresses.
Current behavior:
- if a host reservation does not have an IP address:
- defer to normal dynamic lease creation
- if a host reservation has an IP address, and the IP address overlaps with any subnet within a shared network:
- create/reuse a lease tied to the first subnet that the client class allows
- if a host reservation has an IP address, and the IP address does not overlap with any subnet in a shared network
- create/reuse a lease tied to a subnet unfit for the IP address
Requested behavior:
- if a host reservation does not have an IP address:
- defer to normal dynamic lease creation
- if a host reservation has an IP address, and the IP address overlaps with any subnet within a shared network:
- create/reuse a lease tied to the matching subnet
- if a host reservation has an IP address, and the IP address does not overlap with any subnet in a shared network
- defer to normal dynamic lease creation
I have attached a patch series to implement this behavior for both DHCPv4 and DHCPv6 IA_NA reservations. Descriptions of the patches are below:
- alloc_engine4.patch: implements requested behavior for DHCPv4 reservations
- alloc_engine_tests4.patch: implements tests for requested behavior in DHCPv4
- alloc_engine6.patch: implements requested behavior for DHCPv6 IA_NA reservations
- alloc_engine_tests6.patch: implements tests for requested behavior in DHCPv6kea2.3.5Thomas MarkwalderThomas Markwalderhttps://gitlab.isc.org/isc-projects/kea/-/issues/2623Add commands to [B]LQ hook2023-05-19T16:20:15ZFrancis DupontAdd commands to [B]LQ hookAdd commands to manipulate BLQ tables from the [B]LQ hook.Add commands to manipulate BLQ tables from the [B]LQ hook.outstandingFrancis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/kea/-/issues/2575Segmentation fault using REST API in DHCPv4 HA setting2023-07-18T09:27:20ZcacianoSegmentation fault using REST API in DHCPv4 HA settingHi,
This issue has been reported in the kea-users mailing list yesterday and
Andrei Pavel asked to create an issue here with a few extra details.
I am trying to configure a pair of kea servers running in high
availability mode. Howeve...Hi,
This issue has been reported in the kea-users mailing list yesterday and
Andrei Pavel asked to create an issue here with a few extra details.
I am trying to configure a pair of kea servers running in high
availability mode. However, the servers crash with segfault when I try
to use the HTTP RESP API for some commands. I figured out how to
reproduce the problem in one situation described below.
The server is a Ubuntu 22.04 LTS, running kea 2.2.0 from the repository
https://dl.cloudsmith.io/public/isc/kea-2-2/deb/ubuntu jammy main.
The server is a Xen VM with 2GB of RAM, kernel 5.15.0-43-generic
#46-Ubuntu SMP and glibc 2.35.
This following python script loads a configuration file and calls
config-set using the HTTP API.
```python
#!/usr/bin/python3
#coding: utf-8
import json, requests
with open('bug-config.json') as f:
config = json.load(f)
url = 'http://192.168.89.12:8000/'
headers = {'content-type': 'application/json'}
payload = {}
payload['command'] = 'config-set'
payload['service'] = [ 'dhcp4' ]
payload['arguments'] = config
res = requests.post(url, headers=headers, data=json.dumps(payload))
response = res.json()[0]
print('Set config: ' + response['text'])
```
The configuration file sent using the API is this one, without the
shared-networks section. The problem also happens when I send a complete
configuration, but this small one is enough to reproduce the problem.
The configuration file running in the server when I send the config-set
is the same, but has about 19000 host reservations identified by the
hw-address, distributed in 180 networks that are in 90 shared-networks.
```json
{
"Dhcp4": {
"authoritative": true,
"client-classes": [
{
"name": "718",
"option-data": [
{
"data": "192.168.1.52,192.168.1.53",
"name": "domain-name-servers"
}
]
},
{
"name": "708",
"option-data": [
{
"data": "192.168.137.7,192.168.1.52,192.168.1.53",
"name": "domain-name-servers"
}
]
},
{
"name": "533",
"option-data": [
{
"data": "192.168.137.7,192.168.1.52,192.168.1.53",
"name": "domain-name-servers"
}
]
},
{
"name": "791",
"option-data": [
{
"data": "192.168.148.30,192.168.1.52,192.168.1.53",
"name": "domain-name-servers"
}
]
},
{
"name": "792",
"option-data": [
{
"data": "192.168.148.30,192.168.1.52,192.168.1.53",
"name": "domain-name-servers"
}
]
},
{
"name": "793",
"option-data": [
{
"data": "192.168.148.30,192.168.1.52,192.168.1.53",
"name": "domain-name-servers"
}
]
},
{
"name": "794",
"option-data": [
{
"data": "192.168.148.30,192.168.1.52,192.168.1.53",
"name": "domain-name-servers"
}
]
},
{
"name": "795",
"option-data": [
{
"data": "192.168.148.30,192.168.1.52,192.168.1.53",
"name": "domain-name-servers"
}
]
},
{
"name": "532",
"option-data": [
{
"data":
"192.168.148.22,192.168.148.30,192.168.1.52,192.168.1.53",
"name": "domain-name-servers"
}
]
},
{
"name": "561",
"option-data": [
{
"data": "192.168.2.165,192.168.2.166",
"name": "domain-name-servers"
}
]
},
{
"name": "568",
"option-data": [
{
"data": "192.168.162.105, 192.168.1.52, 192.168.1.53",
"name": "domain-name-servers"
}
]
},
{
"name": "118",
"option-data": [
{
"data": "ifch.ufrgs.br",
"name": "domain-name"
}
]
},
{
"name": "527",
"option-data": [
{
"data":
"192.168.150.20,192.168.150.23,192.168.1.52,192.168.1.53",
"name": "domain-name-servers"
}
]
}
],
"control-socket": {
"socket-name": "/tmp/kea4-ctrl-socket",
"socket-type": "unix"
},
"dhcp-ddns": {
"enable-updates": false
},
"expired-leases-processing": {
"hold-reclaimed-time": 401
},
"hooks-libraries": [
{
"library":
"/usr/lib/x86_64-linux-gnu/kea/hooks/libdhcp_lease_cmds.so"
},
{
"library": "/usr/lib/x86_64-linux-gnu/kea/hooks/libdhcp_bootp.so"
},
{
"library": "/usr/lib/x86_64-linux-gnu/kea/hooks/libdhcp_ha.so",
"parameters": {
"high-availability": [
{
"heartbeat-delay": 10000,
"max-unacked-clients": 20,
"min-ack-delay": 5000,
"mode": "hot-standby",
"peers": [
{
"auto-failover": true,
"name": "dhcp",
"role": "primary",
"url": "http://192.168.89.14:8000/"
},
{
"auto-failover": true,
"name": "dhcp-standby",
"role": "standby",
"url": "http://192.168.89.12:8000/"
}
],
"send-lease-updates": false,
"sync-leases": false,
"this-server-name": "dhcp-standby"
}
]
}
}
],
"host-reservation-identifiers": [
"hw-address"
],
"interfaces-config": {
"dhcp-socket-type": "udp",
"interfaces": [
"eth0/192.168.89.12"
]
},
"ip-reservations-unique": true,
"lease-database": {
"lfc-interval": 3600,
"max-row-errors": 100,
"name": "/var/lib/kea/kea-leases4.csv",
"type": "memfile"
},
"loggers": [
{
"debuglevel": 15,
"name": "kea-dhcp4",
"output_options": [
{
"maxver": 32,
"output": "/var/log/kea/kea-dhcp4-server.log"
}
],
"severity": "INFO"
}
],
"match-client-id": false,
"max-valid-lifetime": 1800,
"min-valid-lifetime": 360,
"option-def": [
{
"code": 252,
"name": "wpad",
"type": "string"
},
{
"code": 128,
"name": "option-128",
"type": "string"
},
{
"code": 129,
"name": "etherboot_options",
"type": "string"
}
],
"reservations-global": false,
"reservations-in-subnet": true,
"reservations-lookup-first": true,
"reservations-out-of-pool": true,
"sanity-checks": {
"lease-checks": "fix-del"
},
"store-extended-info": true,
"valid-lifetime": 1800
}
}
```
When the server crashes then "systemctl status" gives the following output:
```
root@keadhcp-dev-02:/etc/kea# systemctl status isc-kea-dhcp4-server.service
× isc-kea-dhcp4-server.service - Kea IPv4 DHCP daemon
Loaded: loaded (/lib/systemd/system/isc-kea-dhcp4-server.service;
enabled; vendor preset: enabled)
Active: failed (Result: core-dump) since Wed 2022-09-21 18:57:31
UTC; 16min ago
Docs: man:kea-dhcp4(8)
Process: 1231471 ExecStart=/usr/sbin/kea-dhcp4 -c
/etc/kea/kea-dhcp4.conf (code=dumped, signal=SEGV)
Main PID: 1231471 (code=dumped, signal=SEGV)
CPU: 7.494s
Sep 21 18:57:19 keadhcp-dev-02 systemd[1]: Started Kea IPv4 DHCP daemon.
Sep 21 18:57:31 keadhcp-dev-02 systemd[1]: isc-kea-dhcp4-server.service:
Main process exited, code=dumped, status=11/SEGV
Sep 21 18:57:31 keadhcp-dev-02 systemd[1]: isc-kea-dhcp4-server.service:
Failed with result 'core-dump'.
Sep 21 18:57:31 keadhcp-dev-02 systemd[1]: isc-kea-dhcp4-server.service:
Consumed 7.494s CPU time.
```
The crash file has the following data in the first lines:
```
root@keadhcp-dev-02:/etc/kea# head -n 73
/var/crash/_usr_sbin_kea-dhcp4.113.crash
ProblemType: Crash
Architecture: amd64
CrashCounter: 1
Date: Mon Sep 19 18:19:50 2022
DistroRelease: Ubuntu 22.04
ExecutablePath: /usr/sbin/kea-dhcp4
ExecutableTimestamp: 1653069600
ProcCmdline: /usr/sbin/kea-dhcp4 -c /etc/kea/kea-dhcp4.conf
ProcEnviron: Error: [Errno 13] Permission denied: 'environ'
ProcMaps: Error: [Errno 13] Permission denied: 'maps'
ProcStatus:
Name: kea-dhcp4
Umask: 0022
State: S (sleeping)
Tgid: 1159118
Ngid: 0
Pid: 1159118
PPid: 1
TracerPid: 0
Uid: 113 113 113 113
Gid: 118 118 118 118
FDSize: 64
Groups: 118
NStgid: 1159118
NSpid: 1159118
NSpgid: 1159118
NSsid: 1159118
VmPeak: 213420 kB
VmSize: 184160 kB
VmLck: 0 kB
VmPin: 0 kB
VmHWM: 155992 kB
VmRSS: 124736 kB
RssAnon: 110380 kB
RssFile: 14356 kB
RssShmem: 0 kB
VmData: 149112 kB
VmStk: 132 kB
VmExe: 628 kB
VmLib: 17112 kB
VmPTE: 348 kB
VmSwap: 0 kB
HugetlbPages: 0 kB
CoreDumping: 1
THP_enabled: 1
Threads: 5
SigQ: 0/7428
SigPnd: 0000000000000000
ShdPnd: 0000000000000000
SigBlk: 0000000000000000
SigIgn: 0000000000001000
SigCgt: 0000000100004003
CapInh: 0000000000002400
CapPrm: 0000000000002400
CapEff: 0000000000002400
CapBnd: 000001ffffffffff
CapAmb: 0000000000002400
NoNewPrivs: 0
Seccomp: 0
Seccomp_filters: 0
Speculation_Store_Bypass: vulnerable
SpeculationIndirectBranch: always enabled
Cpus_allowed: 000f
Cpus_allowed_list: 0-3
Mems_allowed:
00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000001
Mems_allowed_list: 0
voluntary_ctxt_switches: 136
nonvoluntary_ctxt_switches: 304
Signal: 11
Uname: Linux 5.15.0-43-generic x86_64
UserGroups: N/A
CoreDump: base64
H4sICAAAAAAC/0NvcmVEdW1wAA==
......
```
I extracted the core dump file from the crash file with 'apport-unpack /var/crash/_usr_sbin_kea-dhcp4.113.crash test'
and the output from 'gdb /usr/sbin/kea-dhcp4 CoreDump -ex "thread apply all bt" -ex "quit"' is:
```
GNU gdb (Ubuntu 12.0.90-0ubuntu1) 12.0.90
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/sbin/kea-dhcp4...
(No debugging symbols found in /usr/sbin/kea-dhcp4)
[New LWP 1232251]
[New LWP 1232253]
[New LWP 1232252]
[New LWP 1232254]
[New LWP 1232255]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `/usr/sbin/kea-dhcp4 -c /etc/kea/kea-dhcp4.conf'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x00007f271676eda0 in ?? ()
[Current thread is 1 (Thread 0x7f2719375e80 (LWP 1232251))]
Thread 5 (Thread 0x7f2717b6f640 (LWP 1232255)):
#0 __futex_abstimed_wait_common64 (private=0, cancel=true, abstime=0x0, op=393, expected=0, futex_word=0x555c55628350) at ./nptl/futex-internal.c:57
#1 __futex_abstimed_wait_common (cancel=true, private=0, abstime=0x0, clockid=0, expected=0, futex_word=0x555c55628350) at ./nptl/futex-internal.c:87
#2 __GI___futex_abstimed_wait_cancelable64 (futex_word=futex_word@entry=0x555c55628350, expected=expected@entry=0, clockid=clockid@entry=0, abstime=abstime@entry=0x0, private=private@entry=0) at ./nptl/futex-internal.c:139
#3 0x00007f271aab0ac1 in __pthread_cond_wait_common (abstime=0x0, clockid=0, mutex=0x555c556282d0, cond=0x555c55628328) at ./nptl/pthread_cond_wait.c:503
#4 ___pthread_cond_wait (cond=0x555c55628328, mutex=0x555c556282d0) at ./nptl/pthread_cond_wait.c:627
#5 0x00007f271adfa77d in std::condition_variable::wait(std::unique_lock<std::mutex>&) () from /lib/x86_64-linux-gnu/libstdc++.so.6
#6 0x00007f2719ce2a91 in progschj::ThreadPool::emplace_back_worker(unsigned long)::{lambda()#1}::operator()() const () from /lib/x86_64-linux-gnu/liblog4cplus-2.0.so.3
#7 0x00007f271ae2a2b3 in ?? () from /lib/x86_64-linux-gnu/libstdc++.so.6
#8 0x00007f271aab1b43 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:442
#9 0x00007f271ab43a00 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
Thread 4 (Thread 0x7f2718370640 (LWP 1232254)):
#0 __futex_abstimed_wait_common64 (private=0, cancel=true, abstime=0x0, op=393, expected=0, futex_word=0x555c55628350) at ./nptl/futex-internal.c:57
#1 __futex_abstimed_wait_common (cancel=true, private=0, abstime=0x0, clockid=0, expected=0, futex_word=0x555c55628350) at ./nptl/futex-internal.c:87
#2 __GI___futex_abstimed_wait_cancelable64 (futex_word=futex_word@entry=0x555c55628350, expected=expected@entry=0, clockid=clockid@entry=0, abstime=abstime@entry=0x0, private=private@entry=0) at ./nptl/futex-internal.c:139
#3 0x00007f271aab0ac1 in __pthread_cond_wait_common (abstime=0x0, clockid=0, mutex=0x555c556282d0, cond=0x555c55628328) at ./nptl/pthread_cond_wait.c:503
#4 ___pthread_cond_wait (cond=0x555c55628328, mutex=0x555c556282d0) at ./nptl/pthread_cond_wait.c:627
#5 0x00007f271adfa77d in std::condition_variable::wait(std::unique_lock<std::mutex>&) () from /lib/x86_64-linux-gnu/libstdc++.so.6
#6 0x00007f2719ce2a91 in progschj::ThreadPool::emplace_back_worker(unsigned long)::{lambda()#1}::operator()() const () from /lib/x86_64-linux-gnu/liblog4cplus-2.0.so.3
#7 0x00007f271ae2a2b3 in ?? () from /lib/x86_64-linux-gnu/libstdc++.so.6
#8 0x00007f271aab1b43 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:442
#9 0x00007f271ab43a00 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
Thread 3 (Thread 0x7f2719372640 (LWP 1232252)):
#0 __futex_abstimed_wait_common64 (private=0, cancel=true, abstime=0x0, op=393, expected=0, futex_word=0x555c55628350) at ./nptl/futex-internal.c:57
#1 __futex_abstimed_wait_common (cancel=true, private=0, abstime=0x0, clockid=0, expected=0, futex_word=0x555c55628350) at ./nptl/futex-internal.c:87
#2 __GI___futex_abstimed_wait_cancelable64 (futex_word=futex_word@entry=0x555c55628350, expected=expected@entry=0, clockid=clockid@entry=0, abstime=abstime@entry=0x0, private=private@entry=0) at ./nptl/futex-internal.c:139
#3 0x00007f271aab0ac1 in __pthread_cond_wait_common (abstime=0x0, clockid=0, mutex=0x555c556282d0, cond=0x555c55628328) at ./nptl/pthread_cond_wait.c:503
#4 ___pthread_cond_wait (cond=0x555c55628328, mutex=0x555c556282d0) at ./nptl/pthread_cond_wait.c:627
#5 0x00007f271adfa77d in std::condition_variable::wait(std::unique_lock<std::mutex>&) () from /lib/x86_64-linux-gnu/libstdc++.so.6
#6 0x00007f2719ce2a91 in progschj::ThreadPool::emplace_back_worker(unsigned long)::{lambda()#1}::operator()() const () from /lib/x86_64-linux-gnu/liblog4cplus-2.0.so.3
#7 0x00007f271ae2a2b3 in ?? () from /lib/x86_64-linux-gnu/libstdc++.so.6
#8 0x00007f271aab1b43 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:442
#9 0x00007f271ab43a00 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
Thread 2 (Thread 0x7f2718b71640 (LWP 1232253)):
#0 __futex_abstimed_wait_common64 (private=0, cancel=true, abstime=0x0, op=393, expected=0, futex_word=0x555c55628350) at ./nptl/futex-internal.c:57
#1 __futex_abstimed_wait_common (cancel=true, private=0, abstime=0x0, clockid=0, expected=0, futex_word=0x555c55628350) at ./nptl/futex-internal.c:87
#2 __GI___futex_abstimed_wait_cancelable64 (futex_word=futex_word@entry=0x555c55628350, expected=expected@entry=0, clockid=clockid@entry=0, abstime=abstime@entry=0x0, private=private@entry=0) at ./nptl/futex-internal.c:139
#3 0x00007f271aab0ac1 in __pthread_cond_wait_common (abstime=0x0, clockid=0, mutex=0x555c556282d0, cond=0x555c55628328) at ./nptl/pthread_cond_wait.c:503
#4 ___pthread_cond_wait (cond=0x555c55628328, mutex=0x555c556282d0) at ./nptl/pthread_cond_wait.c:627
#5 0x00007f271adfa77d in std::condition_variable::wait(std::unique_lock<std::mutex>&) () from /lib/x86_64-linux-gnu/libstdc++.so.6
#6 0x00007f2719ce2a91 in progschj::ThreadPool::emplace_back_worker(unsigned long)::{lambda()#1}::operator()() const () from /lib/x86_64-linux-gnu/liblog4cplus-2.0.so.3
#7 0x00007f271ae2a2b3 in ?? () from /lib/x86_64-linux-gnu/libstdc++.so.6
#8 0x00007f271aab1b43 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:442
#9 0x00007f271ab43a00 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
Thread 1 (Thread 0x7f2719375e80 (LWP 1232251)):
#0 0x00007f271676eda0 in ?? ()
#1 0x00007f271b1ebed7 in isc::asiolink::IntervalTimerImpl::~IntervalTimerImpl() () from /lib/x86_64-linux-gnu/libkea-asiolink.so.40
#2 0x00007f271b1f58c6 in ?? () from /lib/x86_64-linux-gnu/libkea-asiolink.so.40
#3 0x00007f271b1e8f8a in ?? () from /lib/x86_64-linux-gnu/libkea-asiolink.so.40
#4 0x00007f271b1ea775 in boost::asio::detail::wait_handler<std::_Bind<void (isc::asiolink::IntervalTimerImpl::*(boost::shared_ptr<isc::asiolink::IntervalTimerImpl>, std::_Placeholder<1>))(boost::system::error_code const&)>, boost::asio::execution::any_executor<boost::asio::execution::context_as_t<boost::asio::execution_context&>, boost::asio::execution::detail::blocking::never_t<0>, boost::asio::execution::prefer_only<boost::asio::execution::detail::blocking::possibly_t<0> >, boost::asio::execution::prefer_only<boost::asio::execution::detail::outstanding_work::tracked_t<0> >, boost::asio::execution::prefer_only<boost::asio::execution::detail::outstanding_work::untracked_t<0> >, boost::asio::execution::prefer_only<boost::asio::execution::detail::relationship::fork_t<0> >, boost::asio::execution::prefer_only<boost::asio::execution::detail::relationship::continuation_t<0> > > >::do_complete(void*, boost::asio::detail::scheduler_operation*, boost::system::error_code const&, unsigned long) () from /lib/x86_64-linux-gnu/libkea-asiolink.so.40
#5 0x00007f271b1f5d3d in isc::asiolink::IOService::poll() () from /lib/x86_64-linux-gnu/libkea-asiolink.so.40
#6 0x0000555c53d66501 in ?? ()
#7 0x00007f271aa46d90 in __libc_start_call_main (main=main@entry=0x555c53d658c0, argc=argc@entry=3, argv=argv@entry=0x7ffd7f3489b8) at ../sysdeps/nptl/libc_start_call_main.h:58
#8 0x00007f271aa46e40 in __libc_start_main_impl (main=0x555c53d658c0, argc=3, argv=0x7ffd7f3489b8, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7ffd7f3489a8) at ../csu/libc-start.c:392
#9 0x0000555c53d689a5 in ?? ()
```
------------------------------------------------------------------------------
The last messages in the log file /var/log/kea/kea-dhcp4-server.log are
these:
```
2022-09-21 19:30:04.973 DEBUG
[kea-dhcp4.commands/1232318.139712599805568]
COMMAND_SOCKET_CONNECTION_OPENED Opened socket 26 for incoming command
connection
2022-09-21 19:30:04.973 DEBUG
[kea-dhcp4.dhcpsrv/1232318.139712599805568]
DHCPSRV_TIMERMGR_RUN_TIMER_OPERATION running operation for timer:
flush-reclaimed-leases
2022-09-21 19:30:04.973 DEBUG
[kea-dhcp4.alloc-engine/1232318.139712599805568]
ALLOC_ENGINE_V4_RECLAIMED_LEASES_DELETE begin deletion of reclaimed
leases expired more than 3600 seconds ago
2022-09-21 19:30:04.973 DEBUG
[kea-dhcp4.dhcpsrv/1232318.139712599805568]
DHCPSRV_MEMFILE_DELETE_EXPIRED_RECLAIMED4 deleting reclaimed IPv4 leases
that expired more than 3600 seconds ago
2022-09-21 19:30:04.973 DEBUG
[kea-dhcp4.alloc-engine/1232318.139712599805568]
ALLOC_ENGINE_V4_RECLAIMED_LEASES_DELETE_COMPLETE successfully deleted 0
expired-reclaimed leases
2022-09-21 19:30:04.973 DEBUG
[kea-dhcp4.dhcpsrv/1232318.139712599805568] DHCPSRV_TIMERMGR_START_TIMER
starting timer: flush-reclaimed-leases
2022-09-21 19:30:04.973 DEBUG
[kea-dhcp4.commands/1232318.139712599805568] COMMAND_SOCKET_READ
Received 3597 bytes over command socket 26
2022-09-21 19:30:04.976 INFO
[kea-dhcp4.commands/1232318.139712599805568] COMMAND_RECEIVED Received
command 'config-set'
2022-09-21 19:30:04.977 INFO [kea-dhcp4.hosts/1232318.139712599805568]
HOSTS_BACKENDS_REGISTERED the following host backend types are
available: mysql postgresql
2022-09-21 19:30:04.977 INFO [kea-dhcp4.dhcpsrv/1232318.139712599805568]
DHCPSRV_CFGMGR_SOCKET_TYPE_SELECT using socket type udp
2022-09-21 19:30:04.977 INFO [kea-dhcp4.dhcpsrv/1232318.139712599805568]
DHCPSRV_CFGMGR_USE_ADDRESS listening on address 192.168.89.12, on
interface eth0
2022-09-21 19:30:04.977 INFO [kea-dhcp4.hooks/1232318.139712599805568]
HOOKS_LIBRARY_CLOSED hooks library
/usr/lib/x86_64-linux-gnu/kea/hooks/libdhcp_lease_cmds.so successfully
closed
2022-09-21 19:30:04.978 INFO [kea-dhcp4.hooks/1232318.139712599805568]
HOOKS_LIBRARY_CLOSED hooks library
/usr/lib/x86_64-linux-gnu/kea/hooks/libdhcp_bootp.so successfully closed
2022-09-21 19:30:04.978 INFO [kea-dhcp4.hooks/1232318.139712599805568]
HOOKS_LIBRARY_CLOSED hooks library
/usr/lib/x86_64-linux-gnu/kea/hooks/libdhcp_ha.so successfully closed
2022-09-21 19:30:04.979 INFO
[kea-dhcp4.ha-hooks/1232318.139712599805568] HA_DEINIT_OK unloading High
Availability hooks library successful
2022-09-21 19:30:04.979 INFO
[kea-dhcp4.bootp-hooks/1232318.139712599805568] BOOTP_UNLOAD Bootp hooks
library has been unloaded
2022-09-21 19:30:04.979 INFO
[kea-dhcp4.lease-cmds-hooks/1232318.139712599805568]
LEASE_CMDS_DEINIT_OK unloading Lease Commands hooks library successful
2022-09-21 19:30:04.980 INFO [kea-dhcp4.hooks/1232318.139712599805568]
HOOKS_LIBRARY_CLOSED hooks library
/usr/lib/x86_64-linux-gnu/kea/hooks/libdhcp_ha.so successfully closed
2022-09-21 19:30:04.980 INFO [kea-dhcp4.hooks/1232318.139712599805568]
HOOKS_LIBRARY_CLOSED hooks library
/usr/lib/x86_64-linux-gnu/kea/hooks/libdhcp_bootp.so successfully closed
2022-09-21 19:30:04.980 INFO [kea-dhcp4.hooks/1232318.139712599805568]
HOOKS_LIBRARY_CLOSED hooks library
/usr/lib/x86_64-linux-gnu/kea/hooks/libdhcp_lease_cmds.so successfully
closed
2022-09-21 19:30:04.982 INFO
[kea-dhcp4.lease-cmds-hooks/1232318.139712599805568] LEASE_CMDS_INIT_OK
loading Lease Commands hooks library successful
2022-09-21 19:30:04.982 INFO [kea-dhcp4.hooks/1232318.139712599805568]
HOOKS_LIBRARY_LOADED hooks library
/usr/lib/x86_64-linux-gnu/kea/hooks/libdhcp_lease_cmds.so successfully
loaded
2022-09-21 19:30:04.982 INFO
[kea-dhcp4.bootp-hooks/1232318.139712599805568] BOOTP_LOAD Bootp hooks
library has been loaded
2022-09-21 19:30:04.982 INFO [kea-dhcp4.hooks/1232318.139712599805568]
HOOKS_LIBRARY_LOADED hooks library
/usr/lib/x86_64-linux-gnu/kea/hooks/libdhcp_bootp.so successfully loaded
2022-09-21 19:30:04.984 INFO
[kea-dhcp4.ha-hooks/1232318.139712599805568] HA_CONFIGURATION_SUCCESSFUL
HA hook library has been successfully configured
2022-09-21 19:30:04.984 WARN
[kea-dhcp4.ha-hooks/1232318.139712599805568]
HA_CONFIG_LEASE_UPDATES_DISABLED lease updates will not be generated
2022-09-21 19:30:04.984 WARN
[kea-dhcp4.ha-hooks/1232318.139712599805568]
HA_CONFIG_LEASE_SYNCING_DISABLED lease database synchronization between
HA servers is disabled
2022-09-21 19:30:04.984 INFO
[kea-dhcp4.ha-hooks/1232318.139712599805568] HA_INIT_OK loading High
Availability hooks library successful
2022-09-21 19:30:04.984 INFO [kea-dhcp4.hooks/1232318.139712599805568]
HOOKS_LIBRARY_LOADED hooks library
/usr/lib/x86_64-linux-gnu/kea/hooks/libdhcp_ha.so successfully loaded
2022-09-21 19:30:04.985 INFO [kea-dhcp4.dhcp4/1232318.139712599805568]
DHCP4_CONFIG_COMPLETE DHCPv4 server has completed configuration: no IPv4
subnets!; DDNS: disabled
2022-09-21 19:30:04.985 INFO [kea-dhcp4.dhcpsrv/1232318.139712599805568]
DHCPSRV_MEMFILE_DB opening memory file lease database: lfc-interval=3600
max-row-errors=100 name=/var/lib/kea/kea-leases4.csv type=memfile universe=4
2022-09-21 19:30:04.985 INFO [kea-dhcp4.dhcpsrv/1232318.139712599805568]
DHCPSRV_MEMFILE_LEASE_FILE_LOAD loading leases from file
/var/lib/kea/kea-leases4.csv.2
2022-09-21 19:30:04.985 INFO [kea-dhcp4.dhcpsrv/1232318.139712599805568]
DHCPSRV_MEMFILE_LEASE_FILE_LOAD loading leases from file
/var/lib/kea/kea-leases4.csv
2022-09-21 19:30:04.985 INFO [kea-dhcp4.dhcpsrv/1232318.139712599805568]
DHCPSRV_MEMFILE_LFC_SETUP setting up the Lease File Cleanup interval to
3600 sec
2022-09-21 19:30:04.986 INFO
[kea-dhcp4.ha-hooks/1232318.139712599805568] HA_LOCAL_DHCP_DISABLE local
DHCP service is disabled while the dhcp-standby is in the WAITING state
2022-09-21 19:30:04.986 INFO
[kea-dhcp4.ha-hooks/1232318.139712599805568] HA_SERVICE_STARTED started
high availability service in hot-standby mode as standby server
```kea2.3.5Razvan BecheriuRazvan Becheriuhttps://gitlab.isc.org/isc-projects/kea/-/issues/2507Replace use of CriticalSection in stat-leaseX-get commands with Memfile_Lease...2023-07-17T13:58:24ZThomas MarkwalderReplace use of CriticalSection in stat-leaseX-get commands with Memfile_LeaseMgr mutex lockThe command handlers for stat-leaseX-get commands create CriticalSections upon entry. We should be able to replace those with simply locking the Memfile lease manager's mutex like so:
```
tmark@wild-dog:stat_cmds (master) $ git diff
dif...The command handlers for stat-leaseX-get commands create CriticalSections upon entry. We should be able to replace those with simply locking the Memfile lease manager's mutex like so:
```
tmark@wild-dog:stat_cmds (master) $ git diff
diff --git a/src/hooks/dhcp/stat_cmds/stat_cmds.cc b/src/hooks/dhcp/stat_cmds/stat_cmds.cc
index 8950bc928f..b9fe1800d2 100644
--- a/src/hooks/dhcp/stat_cmds/stat_cmds.cc
+++ b/src/hooks/dhcp/stat_cmds/stat_cmds.cc
@@ -718,7 +718,9 @@ int
StatCmds::statLease4GetHandler(CalloutHandle& handle) {
try {
LeaseStatCmdsImpl impl;
+#if 0
MultiThreadingCriticalSection cs;
+#endif
return (impl.statLease4GetHandler(handle));
} catch (const std::exception& ex) {
diff --git a/src/lib/dhcpsrv/memfile_lease_mgr.cc b/src/lib/dhcpsrv/memfile_lease_mgr.cc
index afb3259840..86f95d2cd9 100644
--- a/src/lib/dhcpsrv/memfile_lease_mgr.cc
+++ b/src/lib/dhcpsrv/memfile_lease_mgr.cc
@@ -1990,7 +1990,16 @@ Memfile_LeaseMgr::lfcExecute(boost::shared_ptr<LeaseFileType>& lease_file) {
LeaseStatsQueryPtr
Memfile_LeaseMgr::startLeaseStatsQuery4() {
LeaseStatsQueryPtr query(new MemfileLeaseStatsQuery4(storage4_));
+#if 1
+ if (MultiThreadingMgr::instance().getMode()) {
+ std::lock_guard<std::mutex> lock(*mutex_);
+ query->start();
+ } else {
+ query->start();
+ }
+#else
query->start();
+#endif
return(query);
}
```
I compiled with thread-sanitizer on Ubuntu 20.04, and ran kea-dhcp4 stand-alone in MT mode (8 threads), used traffic. I used a script to call socat locally to generate stat-lease4-get() at a rate every 100 ms. Each test started with an empty lease file and ran for sixty seconds. I tested three variations of the code 1: with CriticalSection 2: without CriticalSection or Mutex 3: With Mutex. The results are attached:
[out.txt](/uploads/98731c35c802a4d2a57c43269ba70543/out.txt)
All three versions report one or two race warnings in StringSanitizerImpl, this is known false report.
The version without CS or mutex had almost 90 race warnings emanating from alloc engine, which one would expect. The mutex-ed version is slightly faster than the CriticalSection version, and I suspect the difference would be larger if running HA+MT as a CS would cause both thread pools to pause/resume.
The stat commands do not need to create a CriticalSection and therefore should not. We might consider the same approach for the lease wipe commands.kea2.3.1Thomas MarkwalderThomas Markwalderhttps://gitlab.isc.org/isc-projects/kea/-/issues/2471reservation-get and reservation-get-all do not return subnet-id2023-07-17T13:58:25ZMarcin Godzinareservation-get and reservation-get-all do not return subnet-idAfter implementing isc-projects/kea#2209 we have still 2 commands, that are inconsistent with others and do not return `subnet-id` when it is included in request:
```
Does NOT return `subnet-id` which is mandatory in the request:
reserva...After implementing isc-projects/kea#2209 we have still 2 commands, that are inconsistent with others and do not return `subnet-id` when it is included in request:
```
Does NOT return `subnet-id` which is mandatory in the request:
reservation-get
reservation-get-all
Always returns `subnet-id`:
reservation-get-page
reservation-get-by-hostname
reservation-get-by-id
```kea2.3.0Andrei Pavelandrei@isc.orgAndrei Pavelandrei@isc.orghttps://gitlab.isc.org/isc-projects/kea/-/issues/2465API Reference network6-* command2022-06-30T13:32:02ZPeter DaviesAPI Reference network6-* commandAPI Reference network6-* command
The examples given in the API Reference for some network6-* commands are from network4-* commands
for example:
https://kea.readthedocs.io/en/kea-2.1.6/api.html#network6-addAPI Reference network6-* command
The examples given in the API Reference for some network6-* commands are from network4-* commands
for example:
https://kea.readthedocs.io/en/kea-2.1.6/api.html#network6-addkea2.2.0 - a new stable branchRazvan BecheriuRazvan Becheriuhttps://gitlab.isc.org/isc-projects/kea/-/issues/2233ARM shows "option-data-list" field instead of "option-data" for reservation-add2022-01-14T14:04:10ZAndrei Pavelandrei@isc.orgARM shows "option-data-list" field instead of "option-data" for reservation-addIf you try to `reservation-add` with `"option-data-list"` as the [ARM suggests](https://kea.readthedocs.io/en/latest/api.html#ref-reservation-add), you get `"unsupported configuration parameter 'option-data-list' (:0:0)"`. `"option-data"...If you try to `reservation-add` with `"option-data-list"` as the [ARM suggests](https://kea.readthedocs.io/en/latest/api.html#ref-reservation-add), you get `"unsupported configuration parameter 'option-data-list' (:0:0)"`. `"option-data"` works however.kea2.1.2Francis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/kea/-/issues/2216Small errors in status-get command documentation2022-01-12T18:09:37ZMarcin GodzinaSmall errors in status-get command documentation16.15.19.5 in Kea documentation lacks **"packet-queue-statistics"** field in example response which is included if "multi-threading-enabled" is true.
For example we can add `"packet-queue-statistics": [ 0.0, 0.0, 0.0 ]` after `"packet-qu...16.15.19.5 in Kea documentation lacks **"packet-queue-statistics"** field in example response which is included if "multi-threading-enabled" is true.
For example we can add `"packet-queue-statistics": [ 0.0, 0.0, 0.0 ]` after `"packet-queue-size": 64`
18.3.13 in Kea documentation lists *thread-pool-size* and *packet-queue-size* being returned only when multi-threading is enabled but omits **packet-queue-statistics** in this list.
Issue applicable to dhcpv4 and dhcpv6kea2.1.2Francis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/kea/-/issues/2209reservation-get-by-hostname: subnet-id not in response if it is in request2022-06-30T09:53:14ZAndrei Pavelandrei@isc.orgreservation-get-by-hostname: subnet-id not in response if it is in requestExpected `subnet-id` to be contained in response regardless of arguments.
This is useful when users switch between API calls and they expect the response to be the same when, for example, they parse the response or they chain API calls.Expected `subnet-id` to be contained in response regardless of arguments.
This is useful when users switch between API calls and they expect the response to be the same when, for example, they parse the response or they chain API calls.kea2.1.7Francis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/kea/-/issues/1736Modify HA hook to instantiate CmdHttpListener (and enable client MT)2021-06-28T09:51:56ZTomek MrugalskiModify HA hook to instantiate CmdHttpListener (and enable client MT)This is the sixth ticket in the HA+MT effort. It covers the modifications of the HA hook to instantiate the CmdHttpListener to be able to support multiple parallel incoming connections, as described in the [HA+MT design](https://gitlab.i...This is the sixth ticket in the HA+MT effort. It covers the modifications of the HA hook to instantiate the CmdHttpListener to be able to support multiple parallel incoming connections, as described in the [HA+MT design](https://gitlab.isc.org/isc-projects/kea/-/wikis/designs/HA-MT-Design-for-Multi-threaded-Http-HA-traffic).
Once this ticket is complete, the server-side of the HA hook with become operational. However, to take advantage of it, #1735 will be required.kea1.9.7Thomas MarkwalderThomas Markwalderhttps://gitlab.isc.org/isc-projects/kea/-/issues/1730HA+MT:Create config::CmdHttpListener2021-08-17T15:10:27ZThomas MarkwalderHA+MT:Create config::CmdHttpListenerThis is the first ticket in the HA+MT effort. It covers the implementation of the CmdHttpListener class as described in the HA+MT design:
https://gitlab.isc.org/isc-projects/kea/-/wikis/designs/HA-MT-Design-for-Multi-threaded-Http-HA-t...This is the first ticket in the HA+MT effort. It covers the implementation of the CmdHttpListener class as described in the HA+MT design:
https://gitlab.isc.org/isc-projects/kea/-/wikis/designs/HA-MT-Design-for-Multi-threaded-Http-HA-traffic.
The class will be added to the libkea-cfgclient library (i.e isc::config namespace).
At the completion of the ticket, the class should be fully functional and unit tested, but not instantiated or referenced in production runtime code.kea1.9.6Thomas MarkwalderThomas Markwalderhttps://gitlab.isc.org/isc-projects/kea/-/issues/1716Expose listening socket status in status-get command or maybe add option to m...2022-06-13T14:42:04ZMike KazantsevExpose listening socket status in status-get command or maybe add option to make bind-fails fatalCurrently, when Kea DHCP daemon starts up, something like this can happen:
```
2021-02-20T20:23:22.619 WARN kea-dhcp4.dhcpsrv DHCPSRV_OPEN_SOCKET_FAIL failed to open socket: failed to open socket on interface kea, reason: failed to bind ...Currently, when Kea DHCP daemon starts up, something like this can happen:
```
2021-02-20T20:23:22.619 WARN kea-dhcp4.dhcpsrv DHCPSRV_OPEN_SOCKET_FAIL failed to open socket: failed to open socket on interface kea, reason: failed to bind fallback socket to address 10.67.2.1, port 67, reason: Address already in use - is another DHCP server running?
2021-02-20T20:23:22.619 WARN kea-dhcp4.dhcpsrv DHCPSRV_OPEN_SOCKET_FAIL failed to open socket: failed to open socket on interface kea, reason: failed to bind fallback socket to address 10.67.3.1, port 67, reason: Address already in use - is another DHCP server running?
2021-02-20T20:23:22.619 WARN kea-dhcp4.dhcpsrv DHCPSRV_NO_SOCKETS_OPEN no interface configured to listen to DHCP traffic
```
Iirc it can also not bind sockets if there's no address on the interface, which can be quite common if there's some race condition on e.g. system startup.
These are warnings which indicate that dhcp service is not working and will never work until daemon restart or reconfiguration.
Reporting these as warnings is somewhat different from how most services work on unix/linux.\
For example, if apache/nginx listening sockets are unavailable on startup, they will immediately exit instead of running in an unusable state by default.
It's understandable that multiple sockets can be defined (probably?), and binding some of these can fail, but I'd propose that expected/intuitive default behavior should still likely be to exit with a fatal error if any of sockets defined on startup are unavailable.\
And in fact, Kea already does that with e.g. control sockets - any conflict there results in an immediate exit, but not actual service sockets, which I think is confusing and unexpected default behavior, though it might be documented, and hard to change in a backwards-compatible way at this point.
But regardless of that, I'd propose that there should be at least an obvious and simple way to query Kea for "are you actually listening on any sockets, or just failed to start the service?" question.\
Maybe status-get command would be a good place to return list of listening sockets in, given that it seem to be a status of a very important daemon component.\
My use-case for such query is to check whether Kea daemon should be immediately killed and exit with error from a wrapper script, if it fails to open service sockets after start or reconfiguration.
Is there maybe some other way to check this status or instruct Kea to treat such "warnings" as proper failures that I'm just not aware of?
Don't think I'm good enough with C++ and familiar enough with Kea internals to implement it in any upstream-useful way myself, unfortunately, but wanted to suggest it as a useful feature, or at least create a thread which maybe can be found if someone else also finds this behaviour counter-intuitive, with some kind of workaround suggestion or maybe a resolution.
Thanks for consideration.kea2.1.5Slawek FigielSlawek Figielhttps://gitlab.isc.org/isc-projects/kea/-/issues/1652Comments in API commands2021-04-23T18:41:31ZTomek MrugalskiComments in API commandsThere's a customer who has a nicely commented config file with many commands. He had problems when sending this as API commands. We should look at whether the API parser is able to handle the comments correctly.
the customer reported se...There's a customer who has a nicely commented config file with many commands. He had problems when sending this as API commands. We should look at whether the API parser is able to handle the comments correctly.
the customer reported seeing a 400 http error.kea1.9.7Francis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/kea/-/issues/1391commands lease4-get-by-* returning empty parameters in not consistent way.2022-07-18T12:17:36ZWlodzimierz Wencelcommands lease4-get-by-* returning empty parameters in not consistent way.Example show lease of client that send hostname and client-id; both are returned in `lease4-get-by-* ` commands
```
{'arguments': {'hostname': 'four.hostname.com.'}, 'command': 'lease4-get-by-hostname'}
```
```
{
"arguments": {
"l...Example show lease of client that send hostname and client-id; both are returned in `lease4-get-by-* ` commands
```
{'arguments': {'hostname': 'four.hostname.com.'}, 'command': 'lease4-get-by-hostname'}
```
```
{
"arguments": {
"leases": [
{
"client-id": "00:01:02:03:04:05:06",
"cltt": 1597923930,
"fqdn-fwd": true,
"fqdn-rev": true,
"hostname": "four.hostname.com.",
"hw-address": "08:08:08:08:08:08",
"ip-address": "192.168.50.5",
"state": 0,
"subnet-id": 1,
"valid-lft": 4000
}
]
},
"result": 0,
"text": "1 IPv4 lease(s) found."
}
```
but when client will not send hostname nor client-id response is this:
```
{
"arguments": {
"leases": [
{
"cltt": 1597924174,
"fqdn-fwd": false,
"fqdn-rev": false,
"hostname": "",
"hw-address": "10:10:10:10:10:10",
"ip-address": "192.168.51.10",
"state": 0,
"subnet-id": 2,
"valid-lft": 4000
}
]
},
"result": 0,
"text": "1 IPv4 lease(s) found."
}
```
parameter hostname is included but it's empty, and client-id is missing. It should also be included as an empty parameter.kea2.2.0 - a new stable branchThomas MarkwalderThomas Markwalderhttps://gitlab.isc.org/isc-projects/kea/-/issues/1305status-get should give information about service thread count2020-08-18T20:37:25ZRazvan Becheriustatus-get should give information about service thread countkea1.8.0Razvan BecheriuRazvan Becheriu