[Kea-users] keactrl: returns 0 when a deamon fails to start

[Tomek Mrugalski]

On 04.05.2016 23:22, Patrik Lundin wrote:
> I have been thinking about this some more: would it be feasible to add a
> "background" flag to the daemons? If this was done they might
> be able to do pre-flight checks prior to letting go of the shell.
> 
> I have taken a brief look at the dhcp4 code, and maby
> daemonizing actions could be performed somewhere after calling
> server.init(config_file); if requested by such a flag? This way the
> process could block the terminal until after checking the configuration,
> and either exit with a failure code, or go into the background.
I'm not thrilled about implementing such functionality. Depending on how
Kea was started, it could then potentially behave slightly differently.
I don't know, maybe it's just personal thing as I was tracking an
elusive bug for weeks. It was about file descriptor 0 being closed
mysteriously in the code. Other engineers likely will have a different
opinion on this, though.

> If adding another way of running the process is frowned upon, maby a
> "check the configuration and exit" mode could be added as some other
> flag?
This would be more useful. We do have similar option (-T and -t) in
dhcpd. But this approach is not perfect, either. Kea could check some
aspects (whether the syntax is ok, subnets are reasonable, not using
IPv6 address in IPv4 etc.). However, some things can't really be checked
without starting the whole system. I have at least 3 features in mind
here: opening sockets, connecting to the database and loading hook
libraries. Each of those could have perfectly fine parameters specified,
yet could fail and there's no way to detect it unless we try.

I suppose we could think about test configuration that opens sockets,
loads libs and connects to a database, but that wouldn't be a test
anymore. It would be a full startup followed by immediate shutdown.
Doable, but more complex than simply looking at the config and saying
"yeah, looks ok to me".

So it seems like two types of checks: basic, syntax checks with a bit of
DHCP logic verification and extended checks that verify everything.
Assuming we had infinite engineering time, we could possibly implement
both, but the sad reality makes this somewhat unlikely.

But I agree that having some sort of configuration verification would be
useful. Can you create a ticket for it in Kea tracker (kea.isc.org)?

> Just throwing the ideas out there, I might of course be missing some
> obvious reason why none of these would be good solutions :).
Thanks, that's very useful. Keep them coming.

Tomek