[Kea-users] DHCPv4 lease reservation based on host name (option 12)
Hello,
I would like to implement the following feature with Kea :
Based on DHCPv4 option < host name > (12) provided by clients in DHCP requests,
assign a reserved lease IP address.
Reading Kea documentation, I see that the < reservations > entries can have a <
hostname > field.
However (if I understand correctly) this is not used as a matching criteria on
the request, but rather as information to be provided in the response.
Can you confirm ?
If so, I think the < flex-id > commercial hook would be the solution to my
requirement.
For example with the following configuration, I would be able to reserve the
lease 10.0.0.7 to a client that provides < my.host > in DHCP option < host name
> (12).
This IP address 10.0.0.7 would never be assigned to any other client.
Can you confirm this is correct ?
"Dhcp4": {
"subnet4": [ { ...,
"reservations": [
{
"flex-id": "my.host",
"ip-address": "10.0.0.7"
}
],
} ], # end of subnet definitions
"host-reservation-identifiers": ["flex-id"],
"hooks-libraries": [
{
"library": "/path/libdhcp_flex_id.so",
"parameters": {
"identifier-expression": "option[12]"
}
}
]
}
Lastly, I would like to know if it is possible to obtain an evaluation version
of the < flex-id > commercial hook, to perform some tests ?
Thanks for your answers. :)
Regards,
Nicolas.
This message contains information that may be privileged or confidential and is
the property of the Capgemini Group. It is intended only for the person to whom
it is addressed. If you are not the intended recipient, you are not authorized
to read, print, retain, copy, disseminate, distribute, or use this message or
any part thereof. If you receive this message in error, please notify the
sender immediately and delete all copies of this message.
___
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
Kea-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users
Re: [Kea-users] [Kea] subnet or shared network selected for multiple relays
Thanks Tomek.
I'll have a look at 1.4.0 then. :)
Regards,
Nicolas.
>
> Reviving an old thread, hopefully with some good news.
>
> On 24/11/2017 17:46, Chaigneau, Nicolas wrote:
> > I would like to configure a subnet shared by multiple relays, i.e.
> > that would be chosen for several "giaddr" values.
> >
> > If I'm not mistaken, this was not possible with the basic "subnet4"
> > configuration prior to 1.3.0 (as parameter "relay" does not support a
> > list of relays).
> >
> > Can I achieve that with a shared network in 1.3.0 ?
> No, but you can do it in 1.4.0.
>
> The "relay": { "ip-address": "..." } syntax is now deprecated (but don't
> worry, it will work for couple releases). A new syntax is as follows:
>
> "relay": {
> "ip-addresses": [ "10.0.0.1" ]
> }
>
> This should in principle work for shared networks, but it hasn't been tested
> extensively. User reports more than welcome.
>
> > I've read Kea admin guide but I'm not sure this is possible just with
> > configuration.
> The admin guide for 1.4.0 has its examples updated.
>
> Tomek
>
This message contains information that may be privileged or confidential and is
the property of the Capgemini Group. It is intended only for the person to whom
it is addressed. If you are not the intended recipient, you are not authorized
to read, print, retain, copy, disseminate, distribute, or use this message or
any part thereof. If you receive this message in error, please notify the
sender immediately and delete all copies of this message.
___
Kea-users mailing list
Kea-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users
Re: [Kea-users] Issue building Kea 1.4.0-beta - configure: error: Needs log4cplus library - SOLVED
Hello Francis, thanks for your reply! My system: RedHat RHEL 7.1 x86_64 Compiler: gcc 7.3.0 I've found more information in config.log as you suggested. The issue was: /tmp/cczN32aU.o: In function `main': /home/build/kea-1.4.0-beta/conftest.cpp:34: undefined reference to `log4cplus::Logger::getInstance(std::__cxx11::basic_string, std::allocator > const&)' collect2: error: ld returned 1 exit status I've solved my issue by upgrading to log4cplus 2.0.1. Before that I was using log4cplus 1.2.0-rc3 (somewhat old, released in January 2015, but I did not see the need to upgrade - until now ). (I don't know why it worked with Kea 1.3.0 though.) Regards, Nicolas. > "Chaigneau, Nicolas" writes: > > Executing configure with the following option : > > > > --with-log4cplus > > > > (directory which contains < include > and < lib > sub-dirs for > > Log4cplus) > > > > > > This doesn't seem to work for Kea 1.4.0-beta. > > (It worked with Kea 1.3.0) > > => on which system? > > > I get the following output : > > > > checking log4cplus/logger.h usability... yes checking > > log4cplus/logger.h presence... yes checking for log4cplus/logger.h... > > yes checking for log4cplus library... no > > configure: error: Needs log4cplus library > > > > Any idea ? > > => look at the config.log where the problem is logged with details. > Note we fixed in the past similar problems and if your compiler is not C++11 > compatible by default you can get spurious warnings (this is why on my macOS > I set the CXX environment variable to "g++ --std=c++11" in the shell before > calling autoreconf and ./configure. > > Regards > > Francis Dupont > This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. ___ Kea-users mailing list Kea-users@lists.isc.org https://lists.isc.org/mailman/listinfo/kea-users
[Kea-users] Issue building Kea 1.4.0-beta - configure: error: Needs log4cplus library
Hello, Executing configure with the following option : --with-log4cplus (directory which contains < include > and < lib > sub-dirs for Log4cplus) This doesn't seem to work for Kea 1.4.0-beta. (It worked with Kea 1.3.0) I get the following output : checking log4cplus/logger.h usability... yes checking log4cplus/logger.h presence... yes checking for log4cplus/logger.h... yes checking for log4cplus library... no configure: error: Needs log4cplus library Any idea ? Regards, Nicolas. This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. ___ Kea-users mailing list Kea-users@lists.isc.org https://lists.isc.org/mailman/listinfo/kea-users
Re: [Kea-users] option 54
Option 54 is set automatically by the server (to the IP address on which the
packet was received, I think).
It cannot be an arbitrary value, it is used by clients in DHCPREQUEST messages.
The server will ignore such messages with an option 54 that does not match its
configuration (even if they are unicast to him) because it indicates that the
client is trying to communicate with another server.
What are you trying to do exactly ?
Regards,
Nicolas.
De : Kea-users [mailto:kea-users-boun...@lists.isc.org] De la part de itay cohen
Envoyé : vendredi 11 mai 2018 02:35
À : kea-users@lists.isc.org
Objet : [Kea-users] option 54
hi all
i'm using kea-1.2.0
i'm trying to set
"option-data": [
{ "name": "routers", "data": " 10.0.0.1" },
{ "name": "dhcp-server-identifier", "data":
"10.0.0.1" }
],
now, when kea is trying to send the packet back its being Dropped with this
message,
[kea-dhcp4.bad-packets/19941] DHCP4_PACKET_DROP_0007 [hwtype=1
a8:11:fc:98:fe:dd], cid=[ff:fc:98:fe:dd:00:03:00:01:a8:11:fc:98:fe:dd],
tid=0x4a68f6e1: failed to process packet: Option 54 already present in this
message.
any thoughts ?
thank you,
Itay
This message contains information that may be privileged or confidential and is
the property of the Capgemini Group. It is intended only for the person to whom
it is addressed. If you are not the intended recipient, you are not authorized
to read, print, retain, copy, disseminate, distribute, or use this message or
any part thereof. If you receive this message in error, please notify the
sender immediately and delete all copies of this message.
___
Kea-users mailing list
Kea-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users
Re: [Kea-users] Kea LFC not executed anymore after some time (Kea 1.2.0) + other timers
I can't see anything wrong in the logs... Below, all log messages I got up to the last reclaim-expired-leases execution (executed every second): (and 7 minutes after that a packet is received) (...) 2017-12-01 09:13:39.255 DEBUG [kea-dhcp4.packets/32013] DHCP4_BUFFER_WAIT waiting for next DHCPv4 packet with timeout 1000 ms 2017-12-01 09:13:40.255 DEBUG [kea-dhcp4.dhcpsrv/32013] DHCPSRV_TIMERMGR_RUN_TIMER_OPERATION running operation for timer: reclaim-expired-leases 2017-12-01 09:13:40.255 DEBUG [kea-dhcp4.alloc-engine/32013] ALLOC_ENGINE_V4_LEASES_RECLAMATION_START starting reclamation of expired leases (limit = 0 leases or 100 milliseconds) 2017-12-01 09:13:40.255 DEBUG [kea-dhcp4.dhcpsrv/32013] DHCPSRV_MEMFILE_GET_EXPIRED4 obtaining maximum 0 of expired IPv4 leases 2017-12-01 09:13:40.255 DEBUG [kea-dhcp4.alloc-engine/32013] ALLOC_ENGINE_V4_LEASES_RECLAMATION_COMPLETE reclaimed 0 leases in 0.011 ms 2017-12-01 09:13:40.255 DEBUG [kea-dhcp4.alloc-engine/32013] ALLOC_ENGINE_V4_NO_MORE_EXPIRED_LEASES all expired leases have been reclaimed 2017-12-01 09:13:40.255 DEBUG [kea-dhcp4.dhcpsrv/32013] DHCPSRV_TIMERMGR_START_TIMER starting timer: reclaim-expired-leases 2017-12-01 09:13:40.255 DEBUG [kea-dhcp4.packets/32013] DHCP4_BUFFER_WAIT_INTERRUPTED interrupted wait for the next packet due to timeout, signal or external socket callback (timeout value is 1000) 2017-12-01 09:13:40.255 DEBUG [kea-dhcp4.packets/32013] DHCP4_BUFFER_WAIT waiting for next DHCPv4 packet with timeout 1000 ms 2017-12-01 09:13:41.256 DEBUG [kea-dhcp4.dhcpsrv/32013] DHCPSRV_TIMERMGR_RUN_TIMER_OPERATION running operation for timer: reclaim-expired-leases 2017-12-01 09:13:41.256 DEBUG [kea-dhcp4.alloc-engine/32013] ALLOC_ENGINE_V4_LEASES_RECLAMATION_START starting reclamation of expired leases (limit = 0 leases or 100 milliseconds) 2017-12-01 09:13:41.256 DEBUG [kea-dhcp4.dhcpsrv/32013] DHCPSRV_MEMFILE_GET_EXPIRED4 obtaining maximum 0 of expired IPv4 leases 2017-12-01 09:13:41.256 DEBUG [kea-dhcp4.alloc-engine/32013] ALLOC_ENGINE_V4_LEASES_RECLAMATION_COMPLETE reclaimed 0 leases in 0.013 ms 2017-12-01 09:13:41.256 DEBUG [kea-dhcp4.alloc-engine/32013] ALLOC_ENGINE_V4_NO_MORE_EXPIRED_LEASES all expired leases have been reclaimed 2017-12-01 09:13:41.256 DEBUG [kea-dhcp4.dhcpsrv/32013] DHCPSRV_TIMERMGR_START_TIMER starting timer: reclaim-expired-leases 2017-12-01 09:13:41.256 DEBUG [kea-dhcp4.packets/32013] DHCP4_BUFFER_WAIT_INTERRUPTED interrupted wait for the next packet due to timeout, signal or external socket callback (timeout value is 1000) 2017-12-01 09:13:41.256 DEBUG [kea-dhcp4.packets/32013] DHCP4_BUFFER_WAIT waiting for next DHCPv4 packet with timeout 1000 ms 2017-12-01 09:20:12.634 DEBUG [kea-dhcp4.packets/32013] DHCP4_BUFFER_RECEIVED received buffer from 10.226.0.1:67 to 10.31.19.28:67 over interface eth3 > Are there any additional messages prior to this, indicating what might > have caused it? > > Marcin > > On 04.12.2017 09:32, Chaigneau, Nicolas wrote: > > Hello, > > > > > > Got another occurence of the issue, on 2017 December 1st at 09:12. > > > > This time I had the server running with debug logs. > > I noticed that, not only did the LFC stopped being executed, but also the > > lease reclaiming mechanism (both at the same time). > > > > So I think that the issue is bigger, that all timers stop working. :( > > > > > > egrep "DHCPSRV_MEMFILE_LFC_START|DHCPSRV_TIMERMGR_RUN_TIMER_OPERATION" > > kea1-open-20171202.log > > > > (...) > > 2017-12-01 09:12:42.376 DEBUG [kea-dhcp4.dhcpsrv/32013] > > DHCPSRV_TIMERMGR_RUN_TIMER_OPERATION running operation for timer: > > memfile-lfc > > 2017-12-01 09:12:42.376 INFO [kea-dhcp4.dhcpsrv/32013] > > DHCPSRV_MEMFILE_LFC_START starting Lease File Cleanup > > 2017-12-01 09:12:43.240 DEBUG [kea-dhcp4.dhcpsrv/32013] > > DHCPSRV_TIMERMGR_RUN_TIMER_OPERATION running operation for timer: > > reclaim-expired-leases > > (...) > > 2017-12-01 09:13:40.255 DEBUG [kea-dhcp4.dhcpsrv/32013] > > DHCPSRV_TIMERMGR_RUN_TIMER_OPERATION running operation for timer: > > reclaim-expired-leases > > 2017-12-01 09:13:41.256 DEBUG [kea-dhcp4.dhcpsrv/32013] > > DHCPSRV_TIMERMGR_RUN_TIMER_OPERATION running operation for timer: > > reclaim-expired-leases > > > > No more timer-related logs after this point. > > (Note that the server is still processing DHCP packets correctly.) > > > > > > > > > > Regards, > > Nicolas. > > > >> > >> OK, thanks for the update! > >> > >> For the record, the issue can appear whether Kea receives DHCP packets or > >> not. > >> So you can just start the server and wait :) > >> > >> > >> >
Re: [Kea-users] Kea LFC not executed anymore after some time (Kea 1.2.0)
OK, thanks for the update! For the record, the issue can appear whether Kea receives DHCP packets or not. So you can just start the server and wait :) > I've been running Kea with LFC for 2 days, simulating DHCP requests at > the rate of 1 lease/sec with valid lifetime of 60 seconds. I haven't > reproduced the problem so far. > > Marcin > > On 30.11.2017 09:28, Chaigneau, Nicolas wrote: > > > > > > > > I've restarted Kea a week ago with debug logs, in the hope of seeing > > something when the issue manifests. > > > > No "luck" so far. Still waiting... > > > > > > > > > >> The worker thread seems to be running. > >> The following command (on the Kea process not executing LFC) shows two > >> threads: > >> > >> ps -T -p > >> PID SPID TTY TIME CMD > >> 28268 28268 ?00:00:03 kea-dhcp4 > >> 28268 28269 ?00:00:03 kea-dhcp4 > >> > >> > >> The issue also happened on our lab, so I could try to upgrade to 1.3.0. > >> > >> But I would really prefer to find out the issue with 1.2.0 and fix this > >> version. > >> We've just deployed 1.2.0 on production, having to upgrade now would be... > >> difficult :/ > >> > >> > >> > >>> It would be useful to check if the worker thread triggering timers is > >>> still running or died. The kea-dhcp4 process should run main thread and > >>> the second thread for timers. You could use "ps" or "top" to verify this. > >>> > >>> In the Kea 1.3.0, we have removed the worker thread and made several > >>> significant updates to the timers scheduling. It would be useful it you > >>> could verify whether Kea 1.3.0 also has this issue, but if it is > >>> production environment, it is not good for experiments. > >>> > >>> Marcin > >>> > >>> On 20.11.2017 10:21, Chaigneau, Nicolas wrote: > >>>> The Kea server not executing LFC is still running, so if there's > >>>> something you want me to check... feel free to ask :) > >>>> > >>>> > >>>> > >>>> -Message d'origine- > >>>> De : Marcin Siodelski [mailto:mar...@isc.org] > >>>> > >>>> Nicolas, > >>>> > >>>> Thanks for creating the ticket. We'll have a look and see if we can > >>>> reproduce it here. > >>>> > >>>> Marcin Siodelski > >>>> ISC > >>>> > >>>> On 20.11.2017 09:07, Chaigneau, Nicolas wrote: > >>>>> > >>>>> Observed a 4th occurrence of the issue. > >>>>> > >>>>> Server started on 2017, November 15th at 17:20:47 > >>>>> Last time LFC was executed: on November 19th at 04:50:47 > >>>>> > >>>>> I'll open a ticket. > >>>>> > >>>>> > >>>>> Regards, > >>>>> Nicolas. > >>>>> > >>>>>> > >>>>>> So this is confirmed: LFC is really not executed anymore at some > >>>>>> point, for a reason yet to be determined. > >>>>>> > >>>>>> I'll have a look at the changes between Kea 0.9.1 and 1.2.0. > >>>>>> > >>>>>> > >>>>>> If you think of anything that could help, I'm all ears :) > >>>>>> > >>>>>> > >>>>>> > >>>>>> Regards, > >>>>>> Nicolas. > >>>>>> > >>>>>> > >>>>>> > >>>>>>> Hello Marcin, > >>>>>>> > >>>>>>> > >>>>>>> Thanks for your answer. > >>>>>>> > >>>>>>> > >>>>>>> I was too hasty to suspect the log rotation, this has nothing to do > >>>>>>> with it. Rotation occurs at night between 3 and 4am, and the last log > >>>>>>> I have was in the middle of the day. > >>>>>>> > >>>>>>> Furthermore, I think the issue manifesting after 24H is just a > >>>>>>> coincidence. Before that I've had Kea run for several days before > >>>>>>> seeing the issue. So it seems random... &g
Re: [Kea-users] Kea LFC not executed anymore after some time (Kea 1.2.0)
I've restarted Kea a week ago with debug logs, in the hope of seeing something when the issue manifests. No "luck" so far. Still waiting... > The worker thread seems to be running. > The following command (on the Kea process not executing LFC) shows two > threads: > > ps -T -p > PID SPID TTY TIME CMD > 28268 28268 ?00:00:03 kea-dhcp4 > 28268 28269 ?00:00:03 kea-dhcp4 > > > The issue also happened on our lab, so I could try to upgrade to 1.3.0. > > But I would really prefer to find out the issue with 1.2.0 and fix this > version. > We've just deployed 1.2.0 on production, having to upgrade now would be... > difficult :/ > > > > > It would be useful to check if the worker thread triggering timers is > > still running or died. The kea-dhcp4 process should run main thread and > > the second thread for timers. You could use "ps" or "top" to verify this. > > > > In the Kea 1.3.0, we have removed the worker thread and made several > > significant updates to the timers scheduling. It would be useful it you > > could verify whether Kea 1.3.0 also has this issue, but if it is > > production environment, it is not good for experiments. > > > > Marcin > > > > On 20.11.2017 10:21, Chaigneau, Nicolas wrote: > > > The Kea server not executing LFC is still running, so if there's > > > something you want me to check... feel free to ask :) > > > > > > > > > > > > -Message d'origine- > > > De : Marcin Siodelski [mailto:mar...@isc.org] > > > > > > Nicolas, > > > > > > Thanks for creating the ticket. We'll have a look and see if we can > > > reproduce it here. > > > > > > Marcin Siodelski > > > ISC > > > > > > On 20.11.2017 09:07, Chaigneau, Nicolas wrote: > > >> > > >> Observed a 4th occurrence of the issue. > > >> > > >> Server started on 2017, November 15th at 17:20:47 > > >> Last time LFC was executed: on November 19th at 04:50:47 > > >> > > >> I'll open a ticket. > > >> > > >> > > >> Regards, > > >> Nicolas. > > >> > > >>> > > >>> So this is confirmed: LFC is really not executed anymore at some point, > > >>> for a reason yet to be determined. > > >>> > > >>> I'll have a look at the changes between Kea 0.9.1 and 1.2.0. > > >>> > > >>> > > >>> If you think of anything that could help, I'm all ears :) > > >>> > > >>> > > >>> > > >>> Regards, > > >>> Nicolas. > > >>> > > >>> > > >>> > > >>>> Hello Marcin, > > >>>> > > >>>> > > >>>> Thanks for your answer. > > >>>> > > >>>> > > >>>> I was too hasty to suspect the log rotation, this has nothing to do > > >>>> with it. Rotation occurs at night between 3 and 4am, and the last log > > >>>> I have was in the middle of the day. > > >>>> > > >>>> Furthermore, I think the issue manifesting after 24H is just a > > >>>> coincidence. Before that I've had Kea run for several days before > > >>>> seeing the issue. So it seems random... > > >>>> > > >>>> I don't think there's an issue with logging either, because when I > > >>>> stopped the server after the LFC issue appeared, then I got the normal > > >>>> shutdown logs. > > >>>> > > >>>> I think the LFC is not executed because of the two observations: > > >>>> - No log from Kea saying that LFC is launched > > >>>> - Lease files are not modified anymore (and their last modification > > >>>> date coincides with the last "DHCPSRV_MEMFILE_LFC_START" log from Kea) > > >>>> > > >>>> But you're right, I'm not 100% sure LFC is not executed... > > >>>> > > >>>> > > >>>> So I've launched a little script that does loops over a "ps" to try > > >>>> and catch the LFC process running. > > >>>> It's not fully reliable because if LFC has nothing to do, it may start > > >>>> and end so fast that the ps won't see it. > > >>>&
Re: [Kea-users] [Kea] subnet or shared network selected for multiple relays
Thanks Marcin.
So I guess a hook would be the next best way to do that.
Something configured like:
"Dhcp4": {
:
"hooks-libraries": [
{
"library": "/opt/local/multi-relay-subnets.so",
"parameters": {
"relay-subnets": [
{
"subnet": "192.0.2.0/26",
"relays": [ "192.1.1.1", "192.2.2.2" ]
},
{
"subnet": "...",
"relays": [ ... ]
}
]
}
}
]
}
A hook "subnet4_select" which would:
- loop over the hook parameter "relay-subnets" to find a suitable entry for the
received giaddr,
- and then loop over Kea "subnet4collection" to retrieve the subnet we want,
- and set that in the callout argument "subnet4".
I've seen something similar discussed on the mailing list:
https://www.mail-archive.com/kea-users@lists.isc.org/msg00214.html
Regards,
Nicolas.
>
> Unfortunately, it isn't possible for the shared networks too. The shared
> network pretty much derives parameters from the subnet. Or, maybe I
> should say a subnet derives from the shared network.
>
> Marcin Siodelski
> ISC
>
> On 24.11.2017 18:46, Chaigneau, Nicolas wrote:
> > Hello,
> >
> >
> >
> >
> >
> > I would like to configure a subnet shared by multiple relays, i.e. that
> > would be chosen for several "giaddr" values.
> >
> > If I'm not mistaken, this was not possible with the basic "subnet4"
> > configuration prior to 1.3.0 (as parameter "relay" does not support a
> > list of relays).
> >
> >
> >
> > Can I achieve that with a shared network in 1.3.0 ?
> >
> >
> >
> > I've read Kea admin guide but I'm not sure this is possible just with
> > configuration.
> >
> > I have the impression that "relay" still can only be one element, either
> > for the "shared-networks" or for each of its "subnet4" components.
> >
> >
> >
> >
> >
> >
> >
> > Regards,
> >
> > Nicolas.
> >
This message contains information that may be privileged or confidential and is
the property of the Capgemini Group. It is intended only for the person to whom
it is addressed. If you are not the intended recipient, you are not authorized
to read, print, retain, copy, disseminate, distribute, or use this message or
any part thereof. If you receive this message in error, please notify the
sender immediately and delete all copies of this message.
___
Kea-users mailing list
Kea-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users
Re: [Kea-users] Kea LFC not executed anymore after some time (Kea 1.2.0)
The worker thread seems to be running. The following command (on the Kea process not executing LFC) shows two threads: ps -T -p PID SPID TTY TIME CMD 28268 28268 ?00:00:03 kea-dhcp4 28268 28269 ?00:00:03 kea-dhcp4 The issue also happened on our lab, so I could try to upgrade to 1.3.0. But I would really prefer to find out the issue with 1.2.0 and fix this version. We've just deployed 1.2.0 on production, having to upgrade now would be... difficult :/ > It would be useful to check if the worker thread triggering timers is > still running or died. The kea-dhcp4 process should run main thread and > the second thread for timers. You could use "ps" or "top" to verify this. > > In the Kea 1.3.0, we have removed the worker thread and made several > significant updates to the timers scheduling. It would be useful it you > could verify whether Kea 1.3.0 also has this issue, but if it is > production environment, it is not good for experiments. > > Marcin > > On 20.11.2017 10:21, Chaigneau, Nicolas wrote: > > The Kea server not executing LFC is still running, so if there's something > > you want me to check... feel free to ask :) > > > > > > > > -Message d'origine- > > De : Marcin Siodelski [mailto:mar...@isc.org] > > > > Nicolas, > > > > Thanks for creating the ticket. We'll have a look and see if we can > > reproduce it here. > > > > Marcin Siodelski > > ISC > > > > On 20.11.2017 09:07, Chaigneau, Nicolas wrote: > >> > >> Observed a 4th occurrence of the issue. > >> > >> Server started on 2017, November 15th at 17:20:47 > >> Last time LFC was executed: on November 19th at 04:50:47 > >> > >> I'll open a ticket. > >> > >> > >> Regards, > >> Nicolas. > >> > >>> > >>> So this is confirmed: LFC is really not executed anymore at some point, > >>> for a reason yet to be determined. > >>> > >>> I'll have a look at the changes between Kea 0.9.1 and 1.2.0. > >>> > >>> > >>> If you think of anything that could help, I'm all ears :) > >>> > >>> > >>> > >>> Regards, > >>> Nicolas. > >>> > >>> > >>> > >>>> Hello Marcin, > >>>> > >>>> > >>>> Thanks for your answer. > >>>> > >>>> > >>>> I was too hasty to suspect the log rotation, this has nothing to do with > >>>> it. Rotation occurs at night between 3 and 4am, and the last log I have > >>>> was in the middle of the day. > >>>> > >>>> Furthermore, I think the issue manifesting after 24H is just a > >>>> coincidence. Before that I've had Kea run for several days before seeing > >>>> the issue. So it seems random... > >>>> > >>>> I don't think there's an issue with logging either, because when I > >>>> stopped the server after the LFC issue appeared, then I got the normal > >>>> shutdown logs. > >>>> > >>>> I think the LFC is not executed because of the two observations: > >>>> - No log from Kea saying that LFC is launched > >>>> - Lease files are not modified anymore (and their last modification date > >>>> coincides with the last "DHCPSRV_MEMFILE_LFC_START" log from Kea) > >>>> > >>>> But you're right, I'm not 100% sure LFC is not executed... > >>>> > >>>> > >>>> So I've launched a little script that does loops over a "ps" to try and > >>>> catch the LFC process running. > >>>> It's not fully reliable because if LFC has nothing to do, it may start > >>>> and end so fast that the ps won't see it. > >>>> I tried that with LFC scheduled every 10 seconds. The script catches > >>>> about 2 LFC executions out of 3. > >>>> > >>>> So on the live system on which the LFC appears to not run anymore, I'll > >>>> let the script run for an hour. In this time frame LFC is normally > >>>> executed 6 times. > >>>> If I don't see anything, I'll conclude that LFC is indeed not executed. > >>>> > >>>> > >>>> > >>>> Regards, > >>>> Nicolas. > >>>> > >>>> -Message d'origine- > >>>> De : Marc
Re: [Kea-users] Kea LFC not executed anymore after some time (Kea 1.2.0)
The Kea server not executing LFC is still running, so if there's something you want me to check... feel free to ask :) -Message d'origine- De : Marcin Siodelski [mailto:mar...@isc.org] Nicolas, Thanks for creating the ticket. We'll have a look and see if we can reproduce it here. Marcin Siodelski ISC On 20.11.2017 09:07, Chaigneau, Nicolas wrote: > > Observed a 4th occurrence of the issue. > > Server started on 2017, November 15th at 17:20:47 > Last time LFC was executed: on November 19th at 04:50:47 > > I'll open a ticket. > > > Regards, > Nicolas. > >> >> So this is confirmed: LFC is really not executed anymore at some point, for >> a reason yet to be determined. >> >> I'll have a look at the changes between Kea 0.9.1 and 1.2.0. >> >> >> If you think of anything that could help, I'm all ears :) >> >> >> >> Regards, >> Nicolas. >> >> >> >>> Hello Marcin, >>> >>> >>> Thanks for your answer. >>> >>> >>> I was too hasty to suspect the log rotation, this has nothing to do with >>> it. Rotation occurs at night between 3 and 4am, and the last log I have was >>> in the middle of the day. >>> >>> Furthermore, I think the issue manifesting after 24H is just a coincidence. >>> Before that I've had Kea run for several days before seeing the issue. So >>> it seems random... >>> >>> I don't think there's an issue with logging either, because when I stopped >>> the server after the LFC issue appeared, then I got the normal shutdown >>> logs. >>> >>> I think the LFC is not executed because of the two observations: >>> - No log from Kea saying that LFC is launched >>> - Lease files are not modified anymore (and their last modification date >>> coincides with the last "DHCPSRV_MEMFILE_LFC_START" log from Kea) >>> >>> But you're right, I'm not 100% sure LFC is not executed... >>> >>> >>> So I've launched a little script that does loops over a "ps" to try and >>> catch the LFC process running. >>> It's not fully reliable because if LFC has nothing to do, it may start and >>> end so fast that the ps won't see it. >>> I tried that with LFC scheduled every 10 seconds. The script catches about >>> 2 LFC executions out of 3. >>> >>> So on the live system on which the LFC appears to not run anymore, I'll let >>> the script run for an hour. In this time frame LFC is normally executed 6 >>> times. >>> If I don't see anything, I'll conclude that LFC is indeed not executed. >>> >>> >>> >>> Regards, >>> Nicolas. >>> >>> -Message d'origine- >>> De : Marcin Siodelski [mailto:mar...@isc.org] >>> >>> Nicolas, >>> >>> I think we should start from checking if the issue doesn't stem from the >>> log rotation. If I understand correctly, you're rotating the log file >>> daily. Per your message below, things go weird after around 24 hours >>> since server startup. Is it possible to verify that rotating every 12h >>> would cause the issue to begin after 12h rather than 24h? >>> >>> I can't see anything in the Kea code that could prevent periodic >>> execution of LFC, other than server reconfiguration. You're saying that >>> LFC is not executed because the lease files aren't modified. But, is >>> there any other log output present there? Perhaps the LFC is not >>> executed because of some trouble with logging being a result of log file >>> rotation? We should see if logging generally works fine after log file >>> rotation in the first place. Could you enable more verbose logging to >>> see if any log is produced when the LFC starting message is gone? >>> >>> Marcin Siodelski >>> ISC >>> >>> On 17.11.2017 10:41, Chaigneau, Nicolas wrote: >>>> Hello, >>>> >>>> >>>> I've observed the issue again. >>>> >>>> With a Kea server that does not receive any DHCP packet: >>>> At some point, Kea is still running but LFC is no longer executed. >>>> >>>> In Kea log file we don't have "DHCPSRV_MEMFILE_LFC_START" messages anymore. >>>> And the lease files are not modified on disk (they would be if LFC was >>>> executed, so this is not just a logging issue). >>>> >>>> Kea was started on 2017, Novembe
Re: [Kea-users] Kea LFC not executed anymore after some time (Kea 1.2.0)
Observed a 4th occurrence of the issue. Server started on 2017, November 15th at 17:20:47 Last time LFC was executed: on November 19th at 04:50:47 I'll open a ticket. Regards, Nicolas. > > So this is confirmed: LFC is really not executed anymore at some point, for a > reason yet to be determined. > > I'll have a look at the changes between Kea 0.9.1 and 1.2.0. > > > If you think of anything that could help, I'm all ears :) > > > > Regards, > Nicolas. > > > > > Hello Marcin, > > > > > > Thanks for your answer. > > > > > > I was too hasty to suspect the log rotation, this has nothing to do with > > it. Rotation occurs at night between 3 and 4am, and the last log I have was > > in the middle of the day. > > > > Furthermore, I think the issue manifesting after 24H is just a coincidence. > > Before that I've had Kea run for several days before seeing the issue. So > > it seems random... > > > > I don't think there's an issue with logging either, because when I stopped > > the server after the LFC issue appeared, then I got the normal shutdown > > logs. > > > > I think the LFC is not executed because of the two observations: > > - No log from Kea saying that LFC is launched > > - Lease files are not modified anymore (and their last modification date > > coincides with the last "DHCPSRV_MEMFILE_LFC_START" log from Kea) > > > > But you're right, I'm not 100% sure LFC is not executed... > > > > > > So I've launched a little script that does loops over a "ps" to try and > > catch the LFC process running. > > It's not fully reliable because if LFC has nothing to do, it may start and > > end so fast that the ps won't see it. > > I tried that with LFC scheduled every 10 seconds. The script catches about > > 2 LFC executions out of 3. > > > > So on the live system on which the LFC appears to not run anymore, I'll let > > the script run for an hour. In this time frame LFC is normally executed 6 > > times. > > If I don't see anything, I'll conclude that LFC is indeed not executed. > > > > > > > > Regards, > > Nicolas. > > > > -Message d'origine- > > De : Marcin Siodelski [mailto:mar...@isc.org] > > > > Nicolas, > > > > I think we should start from checking if the issue doesn't stem from the > > log rotation. If I understand correctly, you're rotating the log file > > daily. Per your message below, things go weird after around 24 hours > > since server startup. Is it possible to verify that rotating every 12h > > would cause the issue to begin after 12h rather than 24h? > > > > I can't see anything in the Kea code that could prevent periodic > > execution of LFC, other than server reconfiguration. You're saying that > > LFC is not executed because the lease files aren't modified. But, is > > there any other log output present there? Perhaps the LFC is not > > executed because of some trouble with logging being a result of log file > > rotation? We should see if logging generally works fine after log file > > rotation in the first place. Could you enable more verbose logging to > > see if any log is produced when the LFC starting message is gone? > > > > Marcin Siodelski > > ISC > > > > On 17.11.2017 10:41, Chaigneau, Nicolas wrote: > > > Hello, > > > > > > > > > I've observed the issue again. > > > > > > With a Kea server that does not receive any DHCP packet: > > > At some point, Kea is still running but LFC is no longer executed. > > > > > > In Kea log file we don't have "DHCPSRV_MEMFILE_LFC_START" messages > > > anymore. > > > And the lease files are not modified on disk (they would be if LFC was > > > executed, so this is not just a logging issue). > > > > > > Kea was started on 2017, November 15th at 16:20:23. > > > LFC was first executed 10 minutes later, at 16:30:23. > > > And the last execution of LFC: November 16th, at 16:40:23. > > > Nothing after that... > > > > > > > > > > > > Regards, > > > Nicolas. > > > > > > > > >> Wait... when I restarted the server, I got logs again... before the > > >> shutdown! > > >> So logging actually still worked. I just didn't have anything being > > >> logged. > > >> > > >> 2017-11-15 17:20:45.551 INFO [kea-dhcp4.dhcp4/29754] DHC
Re: [Kea-users] Kea LFC not executed anymore after some time (Kea 1.2.0)
So this is confirmed: LFC is really not executed anymore at some point, for a reason yet to be determined. I'll have a look at the changes between Kea 0.9.1 and 1.2.0. If you think of anything that could help, I'm all ears :) Regards, Nicolas. > Hello Marcin, > > > Thanks for your answer. > > > I was too hasty to suspect the log rotation, this has nothing to do with it. > Rotation occurs at night between 3 and 4am, and the last log I have was in > the middle of the day. > > Furthermore, I think the issue manifesting after 24H is just a coincidence. > Before that I've had Kea run for several days before seeing the issue. So it > seems random... > > I don't think there's an issue with logging either, because when I stopped > the server after the LFC issue appeared, then I got the normal shutdown logs. > > I think the LFC is not executed because of the two observations: > - No log from Kea saying that LFC is launched > - Lease files are not modified anymore (and their last modification date > coincides with the last "DHCPSRV_MEMFILE_LFC_START" log from Kea) > > But you're right, I'm not 100% sure LFC is not executed... > > > So I've launched a little script that does loops over a "ps" to try and catch > the LFC process running. > It's not fully reliable because if LFC has nothing to do, it may start and > end so fast that the ps won't see it. > I tried that with LFC scheduled every 10 seconds. The script catches about 2 > LFC executions out of 3. > > So on the live system on which the LFC appears to not run anymore, I'll let > the script run for an hour. In this time frame LFC is normally executed 6 > times. > If I don't see anything, I'll conclude that LFC is indeed not executed. > > > > Regards, > Nicolas. > > -Message d'origine- > De : Marcin Siodelski [mailto:mar...@isc.org] > > Nicolas, > > I think we should start from checking if the issue doesn't stem from the > log rotation. If I understand correctly, you're rotating the log file > daily. Per your message below, things go weird after around 24 hours > since server startup. Is it possible to verify that rotating every 12h > would cause the issue to begin after 12h rather than 24h? > > I can't see anything in the Kea code that could prevent periodic > execution of LFC, other than server reconfiguration. You're saying that > LFC is not executed because the lease files aren't modified. But, is > there any other log output present there? Perhaps the LFC is not > executed because of some trouble with logging being a result of log file > rotation? We should see if logging generally works fine after log file > rotation in the first place. Could you enable more verbose logging to > see if any log is produced when the LFC starting message is gone? > > Marcin Siodelski > ISC > > On 17.11.2017 10:41, Chaigneau, Nicolas wrote: > > Hello, > > > > > > I've observed the issue again. > > > > With a Kea server that does not receive any DHCP packet: > > At some point, Kea is still running but LFC is no longer executed. > > > > In Kea log file we don't have "DHCPSRV_MEMFILE_LFC_START" messages anymore. > > And the lease files are not modified on disk (they would be if LFC was > > executed, so this is not just a logging issue). > > > > Kea was started on 2017, November 15th at 16:20:23. > > LFC was first executed 10 minutes later, at 16:30:23. > > And the last execution of LFC: November 16th, at 16:40:23. > > Nothing after that... > > > > > > > > Regards, > > Nicolas. > > > > > >> Wait... when I restarted the server, I got logs again... before the > >> shutdown! > >> So logging actually still worked. I just didn't have anything being logged. > >> > >> 2017-11-15 17:20:45.551 INFO [kea-dhcp4.dhcp4/29754] DHCP4_SHUTDOWN > >> server shutdown > >> 2017-11-15 17:20:47.603 INFO [kea-dhcp4.dhcp4/28141] DHCP4_STARTING Kea > >> DHCPv4 server version 1.2.0 starting > >> > >> > >> The only logs I normally have in Kea logs is LFC execution every 10 > >> minutes: > >> > >> 2017-11-16 02:10:47.617 INFO [kea-dhcp4.dhcpsrv/28141] > >> DHCPSRV_MEMFILE_LFC_START starting Lease File Cleanup > >> 2017-11-16 02:10:47.617 INFO [kea-dhcp4.dhcpsrv/28141] > >> DHCPSRV_MEMFILE_LFC_EXECUTE executing Lease File Cleanup (...) > >> > >> > >> I don't have these logs anymore after some time. > >> So... either LFC is no longer executed after a while, or Kea stops writing > >&
Re: [Kea-users] Kea LFC not executed anymore after some time (Kea 1.2.0)
Hello Marcin, Thanks for your answer. I was too hasty to suspect the log rotation, this has nothing to do with it. Rotation occurs at night between 3 and 4am, and the last log I have was in the middle of the day. Furthermore, I think the issue manifesting after 24H is just a coincidence. Before that I've had Kea run for several days before seeing the issue. So it seems random... I don't think there's an issue with logging either, because when I stopped the server after the LFC issue appeared, then I got the normal shutdown logs. I think the LFC is not executed because of the two observations: - No log from Kea saying that LFC is launched - Lease files are not modified anymore (and their last modification date coincides with the last "DHCPSRV_MEMFILE_LFC_START" log from Kea) But you're right, I'm not 100% sure LFC is not executed... So I've launched a little script that does loops over a "ps" to try and catch the LFC process running. It's not fully reliable because if LFC has nothing to do, it may start and end so fast that the ps won't see it. I tried that with LFC scheduled every 10 seconds. The script catches about 2 LFC executions out of 3. So on the live system on which the LFC appears to not run anymore, I'll let the script run for an hour. In this time frame LFC is normally executed 6 times. If I don't see anything, I'll conclude that LFC is indeed not executed. Regards, Nicolas. -Message d'origine- De : Marcin Siodelski [mailto:mar...@isc.org] Envoyé : vendredi 17 novembre 2017 12:18 À : Chaigneau, Nicolas; kea-users@lists.isc.org Objet : Re: [Kea-users] Kea LFC not executed anymore after some time (Kea 1.2.0) Nicolas, I think we should start from checking if the issue doesn't stem from the log rotation. If I understand correctly, you're rotating the log file daily. Per your message below, things go weird after around 24 hours since server startup. Is it possible to verify that rotating every 12h would cause the issue to begin after 12h rather than 24h? I can't see anything in the Kea code that could prevent periodic execution of LFC, other than server reconfiguration. You're saying that LFC is not executed because the lease files aren't modified. But, is there any other log output present there? Perhaps the LFC is not executed because of some trouble with logging being a result of log file rotation? We should see if logging generally works fine after log file rotation in the first place. Could you enable more verbose logging to see if any log is produced when the LFC starting message is gone? Marcin Siodelski ISC On 17.11.2017 10:41, Chaigneau, Nicolas wrote: > Hello, > > > I've observed the issue again. > > With a Kea server that does not receive any DHCP packet: > At some point, Kea is still running but LFC is no longer executed. > > In Kea log file we don't have "DHCPSRV_MEMFILE_LFC_START" messages anymore. > And the lease files are not modified on disk (they would be if LFC was > executed, so this is not just a logging issue). > > Kea was started on 2017, November 15th at 16:20:23. > LFC was first executed 10 minutes later, at 16:30:23. > And the last execution of LFC: November 16th, at 16:40:23. > Nothing after that... > > > > Regards, > Nicolas. > > >> Wait... when I restarted the server, I got logs again... before the shutdown! >> So logging actually still worked. I just didn't have anything being logged. >> >> 2017-11-15 17:20:45.551 INFO [kea-dhcp4.dhcp4/29754] DHCP4_SHUTDOWN server >> shutdown >> 2017-11-15 17:20:47.603 INFO [kea-dhcp4.dhcp4/28141] DHCP4_STARTING Kea >> DHCPv4 server version 1.2.0 starting >> >> >> The only logs I normally have in Kea logs is LFC execution every 10 minutes: >> >> 2017-11-16 02:10:47.617 INFO [kea-dhcp4.dhcpsrv/28141] >> DHCPSRV_MEMFILE_LFC_START starting Lease File Cleanup >> 2017-11-16 02:10:47.617 INFO [kea-dhcp4.dhcpsrv/28141] >> DHCPSRV_MEMFILE_LFC_EXECUTE executing Lease File Cleanup (...) >> >> >> I don't have these logs anymore after some time. >> So... either LFC is no longer executed after a while, or Kea stops writing >> these log messages ? >> >> >> >> >>> A few more detail: >>> >>> >>> This worked fine before (with the same logrotate configuration), with: >>> - Kea 0.9.1 >>> - RHEL 6.4 >>> >>> The issue now appears with: >>> - Kea 1.2.0 >>> - RHEL 7.1 >>> >>> >>> Should I open a ticket for this ? (I'm not sure the problem is with Kea, >>> maybe it's logrotate...) >>> >>> >>> >>>> >>>> Hello, >>>> >>>> >>>> I've set up Kea log rotatio
Re: [Kea-users] Kea LFC not executed anymore after some time (Kea 1.2.0)
Hello, I've observed the issue again. With a Kea server that does not receive any DHCP packet: At some point, Kea is still running but LFC is no longer executed. In Kea log file we don't have "DHCPSRV_MEMFILE_LFC_START" messages anymore. And the lease files are not modified on disk (they would be if LFC was executed, so this is not just a logging issue). Kea was started on 2017, November 15th at 16:20:23. LFC was first executed 10 minutes later, at 16:30:23. And the last execution of LFC: November 16th, at 16:40:23. Nothing after that... Regards, Nicolas. > Wait... when I restarted the server, I got logs again... before the shutdown! > So logging actually still worked. I just didn't have anything being logged. > > 2017-11-15 17:20:45.551 INFO [kea-dhcp4.dhcp4/29754] DHCP4_SHUTDOWN server > shutdown > 2017-11-15 17:20:47.603 INFO [kea-dhcp4.dhcp4/28141] DHCP4_STARTING Kea > DHCPv4 server version 1.2.0 starting > > > The only logs I normally have in Kea logs is LFC execution every 10 minutes: > > 2017-11-16 02:10:47.617 INFO [kea-dhcp4.dhcpsrv/28141] > DHCPSRV_MEMFILE_LFC_START starting Lease File Cleanup > 2017-11-16 02:10:47.617 INFO [kea-dhcp4.dhcpsrv/28141] > DHCPSRV_MEMFILE_LFC_EXECUTE executing Lease File Cleanup (...) > > > I don't have these logs anymore after some time. > So... either LFC is no longer executed after a while, or Kea stops writing > these log messages ? > > > > > > A few more detail: > > > > > > This worked fine before (with the same logrotate configuration), with: > > - Kea 0.9.1 > > - RHEL 6.4 > > > > The issue now appears with: > > - Kea 1.2.0 > > - RHEL 7.1 > > > > > > Should I open a ticket for this ? (I'm not sure the problem is with Kea, > > maybe it's logrotate...) > > > > > > > > > > > > Hello, > > > > > > > > > I've set up Kea log rotation with logrotate. > > > This works for some time, and then it stops working: the new log file > > > stays empty, until the server is restarted. > > > I'm not sure what's going on... has anyone else had this issue ? > > > > > > I'm using the following options for logrotate: > > > > > > daily > > > rotate 30 > > > missingok > > > nocompress > > > copytruncate > > > dateext > > > extension .log > > > > > > > > > I thought "copytruncate" would be good enough, but apparently it is not. > > > > > > Is it possible to send a signal to Kea so that it reopens its log file ? > > > > > > > > > Regards, > > > Nicolas. > > > > > > This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. ___ Kea-users mailing list Kea-users@lists.isc.org https://lists.isc.org/mailman/listinfo/kea-users
Re: [Kea-users] Issue with Kea logging of LFC execution (Kea 1.2.0)
Wait... when I restarted the server, I got logs again... before the shutdown! So logging actually still worked. I just didn't have anything being logged. 2017-11-15 17:20:45.551 INFO [kea-dhcp4.dhcp4/29754] DHCP4_SHUTDOWN server shutdown 2017-11-15 17:20:47.603 INFO [kea-dhcp4.dhcp4/28141] DHCP4_STARTING Kea DHCPv4 server version 1.2.0 starting The only logs I normally have in Kea logs is LFC execution every 10 minutes: 2017-11-16 02:10:47.617 INFO [kea-dhcp4.dhcpsrv/28141] DHCPSRV_MEMFILE_LFC_START starting Lease File Cleanup 2017-11-16 02:10:47.617 INFO [kea-dhcp4.dhcpsrv/28141] DHCPSRV_MEMFILE_LFC_EXECUTE executing Lease File Cleanup (...) I don't have these logs anymore after some time. So... either LFC is no longer executed after a while, or Kea stops writing these log messages ? > A few more detail: > > > This worked fine before (with the same logrotate configuration), with: > - Kea 0.9.1 > - RHEL 6.4 > > The issue now appears with: > - Kea 1.2.0 > - RHEL 7.1 > > > Should I open a ticket for this ? (I'm not sure the problem is with Kea, > maybe it's logrotate...) > > > > > > > Hello, > > > > > > I've set up Kea log rotation with logrotate. > > This works for some time, and then it stops working: the new log file stays > > empty, until the server is restarted. > > I'm not sure what's going on... has anyone else had this issue ? > > > > I'm using the following options for logrotate: > > > > daily > > rotate 30 > > missingok > > nocompress > > copytruncate > > dateext > > extension .log > > > > > > I thought "copytruncate" would be good enough, but apparently it is not. > > > > Is it possible to send a signal to Kea so that it reopens its log file ? > > > > > > Regards, > > Nicolas. > > > This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. ___ Kea-users mailing list Kea-users@lists.isc.org https://lists.isc.org/mailman/listinfo/kea-users
Re: [Kea-users] Issue handling Kea log file rotation with logrotate (Kea 1.2.0)
A few more detail: This worked fine before (with the same logrotate configuration), with: - Kea 0.9.1 - RHEL 6.4 The issue now appears with: - Kea 1.2.0 - RHEL 7.1 Should I open a ticket for this ? (I'm not sure the problem is with Kea, maybe it's logrotate...) > > Hello, > > > I've set up Kea log rotation with logrotate. > This works for some time, and then it stops working: the new log file stays > empty, until the server is restarted. > I'm not sure what's going on... has anyone else had this issue ? > > I'm using the following options for logrotate: > > daily > rotate 30 > missingok > nocompress > copytruncate > dateext > extension .log > > > I thought "copytruncate" would be good enough, but apparently it is not. > > Is it possible to send a signal to Kea so that it reopens its log file ? > > > Regards, > Nicolas. > This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. ___ Kea-users mailing list Kea-users@lists.isc.org https://lists.isc.org/mailman/listinfo/kea-users
[Kea-users] Issue handling Kea log file rotation with logrotate (Kea 1.2.0)
Hello, I've set up Kea log rotation with logrotate. This works for some time, and then it stops working: the new log file stays empty, until the server is restarted. I'm not sure what's going on... has anyone else had this issue ? I'm using the following options for logrotate: daily rotate 30 missingok nocompress copytruncate dateext extension .log I thought "copytruncate" would be good enough, but apparently it is not. Is it possible to send a signal to Kea so that it reopens its log file ? Regards, Nicolas. This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. ___ Kea-users mailing list Kea-users@lists.isc.org https://lists.isc.org/mailman/listinfo/kea-users
Re: [Kea-users] Shared subnets configuration - input needed
Oh... didn't realize this was already in. :) I assume the file is looked for in the same directory as the including file ? Can you also specify absolute file paths ? () And relative paths ? () -Message d'origine- De : Francis Dupont [mailto:fdup...@isc.org] Envoyé : vendredi 1 septembre 2017 13:40 À : Chaigneau, Nicolas Cc : Marcin Siodelski; Kea Users List Objet : Re: [Kea-users] Shared subnets configuration - input needed "Chaigneau, Nicolas" writes: > But it would be even better if we had an "include" directive. I think > it has already been suggested, maybe it's time to add this. => we already have a lexical (*) include as an extension to JSON, e.g.: (PS: lexical as it is handled by flex generated code, for instance you can include unbalanced JSON parts when CPP is syntactic). Regards Francis Dupont <fdup...@isc.org> PS: this feature was added for exactly this use case. It supports recursive includes and raises a fatal error when the include stack depth is greater than 10 (i.e. when it loops). This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. ___ Kea-users mailing list Kea-users@lists.isc.org https://lists.isc.org/mailman/listinfo/kea-users
Re: [Kea-users] [Kea 1.2] configuration - cannot end the last element of a list with a comma
Hello Francis, Thanks for the feedback. I understand that the JSON standard does not allow for trailing commas. There are other things it doesn't allow: comments. But I think we can agree they are very convenient :) Trailing commas are convenient. I think they should be allowed, if there are no drawbacks in doing so. Regards, Nicolas. -Message d'origine- De : Francis Dupont [mailto:fdup...@isc.org] Envoyé : mardi 9 mai 2017 10:15 À : Chaigneau, Nicolas Cc : kea-users@lists.isc.org Objet : Re: [Kea-users] [Kea 1.2] configuration - cannot end the last element of a list with a comma "Chaigneau, Nicolas" writes: > I've noticed that Kea configuration parser is stricter now in Kea 1.2 > (as com pared to 1.1.0). > > Now the last element of a list cannot be terminated with a comma. > Is this on purpose ? => yes, according to the JSON standard (aka ECMA 404) it is forbidden to put a comma ',' before a closing bracket ']' (cf Figure 3 -- array at page 3 of the ECMA pdf). Thanks Francis Dupont <fdup...@isc.org> PS: as it is a bug in the 1.1.0 parser which needs to be fixed (in 1.3, not backward) can you send this incorrect piece of config so I can open a ticket with it? This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. ___ Kea-users mailing list Kea-users@lists.isc.org https://lists.isc.org/mailman/listinfo/kea-users
[Kea-users] [Kea 1.2] configuration - cannot end the last element of a list with a comma
Hello, I've noticed that Kea configuration parser is stricter now in Kea 1.2 (as compared to 1.1.0). Now the last element of a list cannot be terminated with a comma. Is this on purpose ? (Allowing this was convenient for dynamically generated properties...) Regards, Nicolas. This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. ___ Kea-users mailing list Kea-users@lists.isc.org https://lists.isc.org/mailman/listinfo/kea-users
Re: [Kea-users] Wrong values in Kea statistics
Hello, We're upgrading to Kea 1.2, so I won't need a patch for 1.1.0 after all. :) Regards, Nicolas. De : Kea-users [mailto:kea-users-boun...@lists.isc.org] De la part de Chaigneau, Nicolas Envoyé : mercredi 19 avril 2017 15:33 À : Thomas Markwalder; kea-users@lists.isc.org Objet : Re: [Kea-users] Wrong values in Kea statistics Thomas, I would love to use 1.2 :) Timing is unfortunate though. We're currently integrating Kea 1.1.0, and we might not have the time to upgrade to 1.2 when it's available. If this is the case I'll have to fix the issue on 1.1.0 before we ship. If you provide an official patch, it will be easier :) Regards, Nicolas. De : Thomas Markwalder [mailto:tm...@isc.org] Envoyé : mercredi 19 avril 2017 15:20 À : Chaigneau, Nicolas; kea-users@lists.isc.org<mailto:kea-users@lists.isc.org> Objet : Re: [Kea-users] Wrong values in Kea statistics Hi Nicolas: It does affect 1.1.0. We can probably make a patch available, of course we would encourage you to upgrade 1.2. It has lots of shiny new features to play with. Cheers, Thomas On 4/19/17 8:35 AM, Chaigneau, Nicolas wrote: Hello Thomas, I assume this issue also affects Kea 1.1.0 ? If so, would it be possible to have a corrective patch for 1.1.0 ? Regards, Nicolas. De : Kea-users [mailto:kea-users-boun...@lists.isc.org] De la part de Thomas Markwalder Envoyé : mercredi 19 avril 2017 14:08 À : kea-users@lists.isc.org<mailto:kea-users@lists.isc.org> Objet : Re: [Kea-users] Wrong values in Kea statistics Hello Malcom: As per my private replies to you, we have identified the issue. As a matter of expediency, I have created a ticket for your issue: http://kea.isc.org/ticket/5247#ticket and we are working into our Kea 1.2 release which is in beta now. Code freeze for final is Monday. We felt this issue warranted a fix forthwith. You'll need to register: http://kea.isc.org/register to view the ticket. To recap the issue: The v4 server does not increment assigned-leases when expired leases are renewed (same client) or reused (different client). Since we decrement assigned-leases each time we expire a lease (as we should), the assigned-leases stat becomes incorrect with the first reissue of an expired lease. Based on that stats you provided, it looks like client leases expire pretty frequently in your environment as your reclaim-leases stat is quite large. Additionally testing shows a similar error in v6 assigned-nas assigned-pds stats. This will be corrected under the same ticket. Regards, Thomas Markwalder On 4/17/17 9:30 AM, Malcolm Scerri wrote: Hello everyone, I am using Kea socket to obtain statistics per each configured subnet. However, the value of Assigned addresses is exceeding the value of Total addresses. This issue is currently occurring on two servers and on multiple subnets and cannot figure out what might be wrong. I appreciate any help on this matter. Thank you in advance! Malcolm. ___ Kea-users mailing list Kea-users@lists.isc.org<mailto:Kea-users@lists.isc.org> https://lists.isc.org/mailman/listinfo/kea-users This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. ___ Kea-users mailing list Kea-users@lists.isc.org https://lists.isc.org/mailman/listinfo/kea-users
Re: [Kea-users] Wrong values in Kea statistics
Thomas, I would love to use 1.2 :) Timing is unfortunate though. We're currently integrating Kea 1.1.0, and we might not have the time to upgrade to 1.2 when it's available. If this is the case I'll have to fix the issue on 1.1.0 before we ship. If you provide an official patch, it will be easier :) Regards, Nicolas. De : Thomas Markwalder [mailto:tm...@isc.org] Envoyé : mercredi 19 avril 2017 15:20 À : Chaigneau, Nicolas; kea-users@lists.isc.org Objet : Re: [Kea-users] Wrong values in Kea statistics Hi Nicolas: It does affect 1.1.0. We can probably make a patch available, of course we would encourage you to upgrade 1.2. It has lots of shiny new features to play with. Cheers, Thomas On 4/19/17 8:35 AM, Chaigneau, Nicolas wrote: Hello Thomas, I assume this issue also affects Kea 1.1.0 ? If so, would it be possible to have a corrective patch for 1.1.0 ? Regards, Nicolas. De : Kea-users [mailto:kea-users-boun...@lists.isc.org] De la part de Thomas Markwalder Envoyé : mercredi 19 avril 2017 14:08 À : kea-users@lists.isc.org<mailto:kea-users@lists.isc.org> Objet : Re: [Kea-users] Wrong values in Kea statistics Hello Malcom: As per my private replies to you, we have identified the issue. As a matter of expediency, I have created a ticket for your issue: http://kea.isc.org/ticket/5247#ticket and we are working into our Kea 1.2 release which is in beta now. Code freeze for final is Monday. We felt this issue warranted a fix forthwith. You'll need to register: http://kea.isc.org/register to view the ticket. To recap the issue: The v4 server does not increment assigned-leases when expired leases are renewed (same client) or reused (different client). Since we decrement assigned-leases each time we expire a lease (as we should), the assigned-leases stat becomes incorrect with the first reissue of an expired lease. Based on that stats you provided, it looks like client leases expire pretty frequently in your environment as your reclaim-leases stat is quite large. Additionally testing shows a similar error in v6 assigned-nas assigned-pds stats. This will be corrected under the same ticket. Regards, Thomas Markwalder On 4/17/17 9:30 AM, Malcolm Scerri wrote: Hello everyone, I am using Kea socket to obtain statistics per each configured subnet. However, the value of Assigned addresses is exceeding the value of Total addresses. This issue is currently occurring on two servers and on multiple subnets and cannot figure out what might be wrong. I appreciate any help on this matter. Thank you in advance! Malcolm. ___ Kea-users mailing list Kea-users@lists.isc.org<mailto:Kea-users@lists.isc.org> https://lists.isc.org/mailman/listinfo/kea-users This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. ___ Kea-users mailing list Kea-users@lists.isc.org https://lists.isc.org/mailman/listinfo/kea-users
[Kea-users] Lease file format in 1.1.0 ?
Hello, I'm in the process of upgrading to Kea 1.1.0 ; I've noticed that there is now an additional field in the lease file: "state". What is this exactly ? I've looked in Kea administration guide, but could not find a description of the lease file fields. I think this could be a useful addition to the documentation. :) Regards, Nicolas. This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. ___ Kea-users mailing list Kea-users@lists.isc.org https://lists.isc.org/mailman/listinfo/kea-users
Re: [Kea-users] Mozilla sponsorship of Kea
That's great news. And well deserved! :) -Message d'origine- De : Kea-users [mailto:kea-users-boun...@lists.isc.org] De la part de Shane Kerr Envoyé : jeudi 6 octobre 2016 16:33 À : kea-users@lists.isc.org Objet : [Kea-users] Mozilla sponsorship of Kea Hello, I just noticed this: https://blog.mozilla.org/blog/2016/10/03/moss-supports-four-more-open-source-projects-with-300k/ https://www.isc.org/blogs/isc-receives-mozilla-moss-award/ Thanks to Mozilla, and congratulations to the Kea team! :) [ Apologies if this was already posted, I just noticed it. ] Cheers, -- Shane This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. ___ Kea-users mailing list Kea-users@lists.isc.org https://lists.isc.org/mailman/listinfo/kea-users
[Kea-users] kea-dev broken ?
Hello, Is mailing list kea-dev broken ? I didn't receive anything since the last mail I sent on September 15th. I've checked the list archive for September : https://lists.isc.org/pipermail/kea-dev/ There's nothing more recent than September 15th... Regards, Nicolas. This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. ___ Kea-users mailing list Kea-users@lists.isc.org https://lists.isc.org/mailman/listinfo/kea-users
