Support systemd socket activation
Short description
Close issue #956: add support for systemd socket activation based on the fd/fdgram syntax "invented" by caddy for addresses.
Long description
This PR adds support to the webserver-address and local-address options for the fd:FD and fdgram:FD syntax. This allows pdns to be handed over socket file descriptors when it is started by systemd upon the first client connection to one of these sockets. Indirectly, this provides support for unix domain sockets (both abstract and non-abstract) sockets for the udp and tcp resolvers, as well as the api server.
Checklist
I have:
- [x] read the CONTRIBUTING.md document
- [x] compiled this code
- [x] tested this code
- [x] included documentation (including possible behaviour changes)
- [ ] documented the code
- [ ] added or modified regression test(s)
- [ ] added or modified unit test(s)
- [ ] checked that this code was merged to master
Pull Request Test Coverage Report for Build 14703259223
Warning: This coverage report may be inaccurate.
This pull request's base commit is no longer the HEAD commit of its target branch. This means it includes changes from outside the original pull request, including, potentially, unrelated coverage changes.
- For more information on this, see Tracking coverage changes with pull request builds.
- To avoid this issue with future PRs, see these Recommended CI Configurations.
- For a quick fix, rebase this PR at GitHub. Your next report should be accurate.
Details
- 0 of 0 changed or added relevant lines in 0 files are covered.
- No unchanged relevant lines lost coverage.
- Overall first build on ml/systemd-listen at 61.65%
| Totals | |
|---|---|
| Change from base Build 14663506638: | 61.7% |
| Covered Lines: | 102669 |
| Relevant Lines: | 133191 |
💛 - Coveralls
I reviewed the first build failure. It looks like the linker cannot find sd_listen_fds BUT I double-checked and I see in the configure step that:
checking for sd_listen_fds in -lsystemd... yes
and that the linked is indeed including -lsystemd in its link arguments.
I am not familiar with the pdns CI infra but could it be that the build is not using the exact same execution environment used during configure ?
The error happens when linking the testrunner, which is the binary running the unit tests. It is indeed not linking against libsystemd.
@miodvallat hi, I believe this version should fix the previously-reported build failure because it does not depend on libsystemd0 anymore.
Would it be possible to let the CI workflow run to see if this version works with them and if not, let me track this down over next weekend ?
Are tidy warnings considered errors by the CI ?
i.e., am I supposed to fix every single warning in existing code that I modify to pass the CI ?
Are tidy warnings considered errors by the CI ?
Yes. That's the evil part of it.
i.e., am I supposed to fix every single warning in existing code that I modify to pass the CI ?
Yes, although in some cases (e.g. C-style casts in bind calls) it is perfectly acceptable to add a NOLINT comment to silence that particular diagnostic.