[Kea-users] kea-dhcp4 service failing to start with 'cannot open shared object file'
duress at mailbox.org
duress at mailbox.org
Fri Feb 20 07:18:09 UTC 2026
I tried truncating the library path value to just the file base name:
<...> "library": "libdhcp_ha.so", <...>
the changed path value was reflected in the error message I got after starting the service again, but it didn't seem to improve the issue at all:
Feb 19 23:08:23 diorite kea-dhcp4[4551]: ERROR HOOKS_OPEN_ERROR failed to open hook library libdhcp_ha.so: libkea-dhcpsrv.so.145: cannot open shared object file: No such file or directory
I don't see any issues loading dependencies for libdhcp_ha.so, and there's an error as expected for the nonexistent file.
root at diorite:/etc/kea# ldd /usr/local/lib/aarch64-linux-gnu/kea/hooks/libdhcp_ha.so
linux-vdso.so.1 (0x0000ffff83b55000)
libkea-dhcpsrv.so.145 => /usr/local/lib/aarch64-linux-gnu/libkea-dhcpsrv.so.145 (0x0000ffff83650000)
libkea-process.so.104 => /usr/local/lib/aarch64-linux-gnu/libkea-process.so.104 (0x0000ffff835e0000)
libkea-stats.so.64 => /usr/local/lib/aarch64-linux-gnu/libkea-stats.so.64 (0x0000ffff83590000)
libkea-config.so.96 => /usr/local/lib/aarch64-linux-gnu/libkea-config.so.96 (0x0000ffff834f0000)
libkea-http.so.99 => /usr/local/lib/aarch64-linux-gnu/libkea-http.so.99 (0x0000ffff833a0000)
libkea-dhcp.so.124 => /usr/local/lib/aarch64-linux-gnu/libkea-dhcp.so.124 (0x0000ffff831f0000)
libkea-hooks.so.134 => /usr/local/lib/aarch64-linux-gnu/libkea-hooks.so.134 (0x0000ffff83190000)
libkea-cc.so.95 => /usr/local/lib/aarch64-linux-gnu/libkea-cc.so.95 (0x0000ffff83110000)
libkea-asiolink.so.102 => /usr/local/lib/aarch64-linux-gnu/libkea-asiolink.so.102 (0x0000ffff83070000)
libkea-log.so.86 => /usr/local/lib/aarch64-linux-gnu/libkea-log.so.86 (0x0000ffff83020000)
libkea-util.so.116 => /usr/local/lib/aarch64-linux-gnu/libkea-util.so.116 (0x0000ffff82f80000)
libkea-exceptions.so.55 => /usr/local/lib/aarch64-linux-gnu/libkea-exceptions.so.55 (0x0000ffff82f50000)
libcrypto.so.3 => /lib/aarch64-linux-gnu/libcrypto.so.3 (0x0000ffff82ad0000)
libstdc++.so.6 => /lib/aarch64-linux-gnu/libstdc++.so.6 (0x0000ffff82840000)
libgcc_s.so.1 => /lib/aarch64-linux-gnu/libgcc_s.so.1 (0x0000ffff82800000)
libc.so.6 => /lib/aarch64-linux-gnu/libc.so.6 (0x0000ffff82640000)
/lib/ld-linux-aarch64.so.1 (0x0000ffff83b10000)
libkea-eval.so.97 => /usr/local/lib/aarch64-linux-gnu/libkea-eval.so.97 (0x0000ffff82590000)
libkea-dhcp_ddns.so.79 => /usr/local/lib/aarch64-linux-gnu/libkea-dhcp_ddns.so.79 (0x0000ffff82510000)
libkea-database.so.87 => /usr/local/lib/aarch64-linux-gnu/libkea-database.so.87 (0x0000ffff824c0000)
libkea-cryptolink.so.75 => /usr/local/lib/aarch64-linux-gnu/libkea-cryptolink.so.75 (0x0000ffff82490000)
libkea-cfgrpt.so.3 => /usr/local/lib/aarch64-linux-gnu/libkea-cfgrpt.so.3 (0x0000ffff82460000)
libssl.so.3 => /lib/aarch64-linux-gnu/libssl.so.3 (0x0000ffff82390000)
libkea-dns.so.83 => /usr/local/lib/aarch64-linux-gnu/libkea-dns.so.83 (0x0000ffff822a0000)
libkea-log-interprocess.so.4 => /usr/local/lib/aarch64-linux-gnu/libkea-log-interprocess.so.4 (0x0000ffff82270000)
liblog4cplus-2.0.so.3 => /lib/aarch64-linux-gnu/liblog4cplus-2.0.so.3 (0x0000ffff821d0000)
libm.so.6 => /lib/aarch64-linux-gnu/libm.so.6 (0x0000ffff82120000)
root at diorite:/etc/kea# ldd /usr/local/lib/aarch64-linux-gnu/kea/hooks/libdhcp_nosuchfile.so
ldd: /usr/local/lib/aarch64-linux-gnu/kea/hooks/libdhcp_nosuchfile.so: No such file or directory
> On 02/20/2026 6:44 AM CET Razvan Becheriu <razvan at isc.org> wrote:
>
>
>
> can you run:
>
> ldd /usr/local/lib/aarch64-linux-gnu/kea/hooks/libdhcp_nosuchfile.so
>
> and
>
> ldd /usr/local/lib/aarch64-linux-gnu/kea/hooks/libdhcp_ha.so
>
> check that all dependencies can be resolved.
>
> Regards,
> Razvan
>
>
>
>
>
>
>
>
> > ---------------------------------------------
> > From: Razvan <razvan at isc.org>
> > To: Kea <kea-users at lists.isc.org>
> > Date: Friday, 20 February 2026 7:37 AM EET
> > Subject: Re: [Kea-users] kea-dhcp4 service failing to start with 'cannot open shared object file'
> >
> > Hi,
> >
> > Kea can load hook libraries from default path just by specifying the hook name:
> >
> >
> > "library": "libdhcp_nosuchfile.so"
> >
> >
> > You can try this and see if it is any different.
> > I'll try to replicate the issue using my rpi. Will let you know how it goes.
> >
> > Regards,
> > Razvan
> >
> >
> > > ---------------------------------------------
> > > From: Andrew <kea-users at lists.isc.org>
> > > To: kea-users <kea-users at lists.isc.org>
> > > Cc: Andrew <duress at mailbox.org>
> > > Date: Friday, 20 February 2026 12:34 AM EET
> > > Subject: [Kea-users] kea-dhcp4 service failing to start with 'cannot open shared object file'
> > >
> > > Hi, I'm trying to set up a hot-standby redundant dhcp server for my home network and I'm having a real struggle trying to get the kea-dhcp4 daemon to find and load the libdhcp_ha.so library hook so that it can run in HA mode.
> > > It's working great when I don't ask it to load the HA library hook, but I'm not having any luck with loading the .so. When I try to start the official ubuntu-package-provided kea-dhcp4-server systemd service, it reports the following:
> > > ERROR HOOKS_OPEN_ERROR failed to open hook library /usr/local/lib/aarch64-linux-gnu/kea/hooks/libdhcp_nosuchfile.so: /usr/local/lib/aarch64-linux-gnu/kea/hooks/libdhcp_nosuchfile.so: cannot open shared object file: No such file or directory
> > >
> > > I believe the issue being reported by the service in my system logs is actually something other than a failed read operation on the listed path, and I can explain my reasoning for drawing this conclusion.
> > > I am hoping someone with the patience to read all this can suggest something I should try that I haven't thought of yet, or point out an error that I've made, that will help me get my HA pair online! thanks in advance for your attention.
> > >
> > > Here's a list of the things I have tried so far to fix this issue in approximate chronological order:
> > > * I manually confirmed that the file exists, by copying the full file name and path directly from the error message and pasting it into the terminal. the file exists.
> > >
> > > * checked the unix file permissions on the .so itself (at /usr/local/lib/aarch64-linux-gnu/kea/hooks/libdhcp_sh.so), and also of each directory in that file path all the way down to /usr.
> > > all have mode o+r set, and I have confirmed that I can read the contents of the file from a shell running as the kea user (_kea on my system). it is not a file permissions error.
> > >
> > > * checked for enhanced access control subsystems. selinux is not installed on this server. apparmor is installed, and when I checked my kernel log I found that apparmor was reporting some blocked access to the library hook file in question.
> > > I addressed these by updating the apparmor profile for /usr/sbin/kea-dhcp4, which required adding explicit permits for the r and m masks.
> > > I made these changes by hand at first, then reset and used the aa-genprof tool from the official apparmor-utils package which generated the same set of changes I had applied by hand. These changes fixed the apparmor permissions conflict that was reported in my kernel log.
> > > I confirmed that apparmor was no longer responsible for blocking access to the file by shutting off apparmor protections system-wide, which did not fix the issue.
> > >
> > > * I copied the target .so file to a new directory under /etc/kea/lib/, and updated the service configs and the apparmor profile to point at this new file location.
> > > The service continued to report that it cannot open the file because it does not exist, this time naming the new path under /etc/kea/lib/. I again copy-pasted the path from the error message to ensure I hadn't made any errors in my typing.
> > > This didn't produce any positive results, so I reverted the configs to point to the default path to avoid unnecessary complication in further debugging.
> > >
> > > * I found the presented troubleshooting advice in the official kea-dhcp4-server install guide from ISC, which indicates that in cases exactly like the one I was dealing with, one should run ldconfig with root permissions to update the linker cache. I did this.
> > > I checked that the directory path containing the library was listed in a file under /etc/ld.so.conf.d/. I checked that /etc/ld.so.conf.d/ was correctly included in /etc/ld.so.conf. I ran ldconfig again as root while explicitly passing the directory immediately containing the .do file.
> > > I ran ldconfig -p | grep to confirm that the desired shared object file was present in the cache, and that it was indexed at the expected file path, which it was.
> > > Out of pure superstition, I even rebooted the server and checked again -- still present in the cache at the correct path.
> > >
> > > * I opened the systemd service unit file to look for clues about any restricted filesystem access, system call capabilities, or anything else of this nature. I didn't find any in the unit file for this service.
> > >
> > > * I explicitly added LD_LIBRARY_PATH=/usr/local/lib/aarch64-linux-gnu/kea/hooks to the service's environment variables exposed by systemd, then reloaded the systemd daemon to read the unit file changes. no help.
> > >
> > > * I inserted strace into the unit file exec line to report any system calls related to the target file, reloaded the systemd daemon, and attempted to start the service again.
> > > For comparison, I edited the service config at /etc/kea/kea-dhcp4.conf and the strace invocation in the service unit file to look for a known-bogus .so file in the same directory, reloaded the daemon again, and started the service again.
> > > Comparing the strace output from the two calls, there is a clear difference between the system calls and results reported by strace. In the output from the service start with a known-bad file path, strace reports a single openat() system call to the expected file, which as expected returns -1 with errno ENOENT.
> > > By comparison, the strace output from the service start with configs pointing to the real .so file which should be accessible to the service shows 6 system calls related to the .so file in question: openat(), read(), fstat(), mmap(), mmap(), close(). none of these system calls are shown to have errored with an associated errno code, or to have returned with a negative value.
> > > At this point I'm not really sure where to go, I am intimidated by the prospect of trying to dive into the kea-dhcp codebase and figure out what is reporting an ENOENT-related error message when there (seemingly, to my eyes) doesn't seem to be any such error occurring.
> > >
> > > I am using binaries and config files as provided from the Ubuntu repos (24.04, arm64), running on a raspberry pi 5, unmodified except as mentioned above and for miscellaneous config changes to /etc/kea/kea-dhcp4.conf to suit the needs of my network.
> > >
> > > The debian packages I'm using are as follows:
> > > ii kea-admin 2.4.1-3ubuntu0.1 arm64 Administration utilities for Kea DHCP server
> > > ii kea-common 2.4.1-3ubuntu0.1 arm64 Common libraries for the Kea DHCP server
> > > ii kea-dev 2.4.1-3ubuntu0.1 arm64 Development headers for Kea DHCP server
> > > ii kea-dhcp4-server 2.4.1-3ubuntu0.1 arm64 IPv4 DHCP server
> > >
> > > The kea version number reported by the binary that shipped with the above packages is 3.1.5
> > >
> > > I am putting a copy of some relevant terminal buffers and config files up on my public webserver for reference, links to follow:
> > >
> > > (config files doctored to target a nonexistent libdhcp_nosuchfile.so)
> > > https://pdxlents.online/kea-dhcp4.conf.bad_configs.txt
> > > https://pdxlents.online/systemd_unit_file.bad_configs.txt
> > > https://pdxlents.online/terminal_log.bad_configs.txt
> > >
> > > (config files targeting an actually existing libdhcp_ha.so)
> > > https://pdxlents.online/kea-dhcp4.conf.good_configs.txt
> > > https://pdxlents.online/terminal_log.good_configs.txt
> > > https://pdxlents.online/systemd_unit_file.good_configs.txt
> > >
> > > (version output from my server binary)
> > > https://pdxlents.online/kea-dhcp4_-V.txt
> > >
> > > Thanks again for reading, and for any advice or suggestions!
> > >
> >
> --
> 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 at lists.isc.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/kea-users/attachments/20260220/02ba4f4c/attachment-0001.htm>
More information about the Kea-users
mailing list