Created attachment 248987 [details] patch for dns/knot-resolver/files kresd.in and krescachegc.in dns/knot-resolver/files/kresd.in lacks activation of defined status_cmd="${name}_status" dns/knot-resolver/files/krescachegc.in needed full clean-up: #) daemon didn't start due to missing '-c <resolver_cache>' #) missing 'start', 'stop' and 'status' functionality added HTH and regards, Michael
Created attachment 251816 [details] knot-resolver rc I delved in this report numerous time, but never was able to solve everything at once, as there is a number of problems/conflicts within just a few lines. - /var/run/kresd is created as kresd, with wrong permissions, which are overwritten in kresd's rc script at the start routine. - /var/run/kresd needs to be 700 or else krescachegc will complain it's not existing or not an LMDB dir. - daemon (for kresd) needs to be running as root - I guess because above reason - kresd however is running as kresd (if you tell so in it's config). - daemon (for krescachegc) can be running as kresd (...?) '-c <resolver_cache>' is indeed something which became problematic. status_cmd="${name}_status" indeed was missing, while the routine was in place. However, -AFAIK- in krescachegc's rc script there is no need to have explicit start/stop/status routine. Although it could be added if there is a good reason for it. As far as I could test this patch would/should solve all the mentioned issues. All feedback is appreciated.
(In reply to Leo Vandewoestijne from comment #1) Disclaimer: I stopped using knot-resolver, mainly due to the reason mentioned in Bug 277332 (knot3 and knot-resolver cannot run in parallel within a service jail). I am back to knot3 and unbound as resolver. But I did apply your patch and installed knot-resolver in a test jail without /var/run/kresd directory with an /etc/rc.conf as follows: kresd_enable="YES" kresd_user="kresd" kresd_group="kresd" krescachegc_enable="YES" krescachegc_millis="600000" After the isntallation of a patched dns/knot-resolver package I end up with: MW-test|root> ls -alR /var/run/kresd/ total 9 drwx------ 2 kresd kresd 2 Jul 4 14:37 . drwxr-xr-x 3 root wheel 14 Jul 4 15:17 .. Now I do a service kresd start: MW-test|root> ls -alR /var/run/kresd total 27 drwx------ 3 kresd kresd 6 Jul 4 15:18 . drwxr-xr-x 4 root wheel 15 Jul 4 15:18 .. drwxr-x--- 2 root kresd 3 Jul 4 15:18 control -rw-r----- 1 root kresd 10485760 Jul 4 15:18 data.mdb -rw------- 1 root kresd 5 Jul 4 15:18 kresd.pid -rw-r----- 1 root kresd 8192 Jul 4 15:18 lock.mdb /var/run/kresd/control: total 10 drwxr-x--- 2 root kresd 3 Jul 4 15:18 . drwx------ 3 kresd kresd 6 Jul 4 15:18 .. srwxr-xr-x 1 root kresd 0 Jul 4 15:18 kresd.sock NOTE: user is root! Now, I do a service krescachegc start and end up with ever repeating: Jul 4 15:19:53 <daemon.notice> test.mer-waases.lan krescachegc[68938]: Knot Resolver Cache Garbage Collector, version 5.7.2 Jul 4 15:19:53 <daemon.notice> test.mer-waases.lan krescachegc[68938]: [cache ] LMDB error: Permission denied Jul 4 15:19:53 <daemon.notice> test.mer-waases.lan krescachegc[68938]: Error opening Resolver cache (Permission denied). Jul 4 15:19:53 <daemon.notice> test.mer-waases.lan krescachegc[68938]: Error (invalid parameter) Processes running are: MW-test|root> ps Af PID TT STAT TIME COMMAND 68871 - IsJ 0:00.00 daemon: /usr/local/sbin/kresd[68872] (daemon) 68872 - SJ 0:00.11 /usr/local/sbin/kresd -c /usr/local/etc/knot-resolver/kresd.conf -n -q /var/run/kresd 68938 - SsJ 0:00.01 daemon: /usr/local/sbin/kres-cache-gc[69118] (daemon) Only after chown kresd /var/run/kresd/*.mdb kres-cache-gc starts: MW-test|root> ps Af PID TT STAT TIME COMMAND 68871 - IsJ 0:00.00 daemon: /usr/local/sbin/kresd[68872] (daemon) 68872 - SJ 0:00.11 /usr/local/sbin/kresd -c /usr/local/etc/knot-resolver/kresd.conf -n -q /var/run/kresd 69579 - IsJ 0:00.01 daemon: /usr/local/sbin/kres-cache-gc[69613] (daemon) 69613 - IJ 0:00.00 /usr/local/sbin/kres-cache-gc -c /var/run/kresd -d 600000 > However, -AFAIK- in krescachegc's rc script there is no need to have explicit > start/stop/status routine. > Although it could be added if there is a good reason for it. kill -9 69613 69579 - SsJ 0:00.01 daemon: /usr/local/sbin/kres-cache-gc[69850] (daemon) 69850 - SJ 0:00.01 /usr/local/sbin/kres-cache-gc -c /var/run/kresd -d 600000 See, 69579 immediately restarts 69850 Only a kill -9 69579 69850 will stop kres-cache-gc Thus, I do opt for explicit start/stop/status routines HTH and thanks for coming back on this issue, Michael
Forgot to mention that 1) my feedback also adresses Bug 277950 2) knot-resolver is fully functional with your patch 3) only kres-cache-gc fails
Created attachment 252079 [details] knot-resolver rc and etc. > only kres-cache-gc fails > Further I see that users kresd (nor daemon) still are unable to create LMDB structure. Contrary when cleaning up cache I encounterd files immutable to the 'kresd' user. For as far as I see the current commands (after this latest patch) are successful. > I do opt for explicit start/stop/status routines > Undeniable makes sense, yes. Anyway, this latest modification is also addressing restarts correctly. Indeed using some custom routines. And avoiding pid files. > Only after chown kresd /var/run/kresd/*.mdb kres-cache-gc starts: > In my testing I -now- see those files being removed at stop, and at start recreated correctly as kresd:kresd > NOTE: user is root! > 'daemon' processes should be root, while 'kresd' and 'kres-cache-gc' should be user 'kresd' (or custom choise) now. So in summary; this patch is be perfect.
After applying your patch #252079 I installed knot-resolver in a vanilla test jail, applied 'service kresd start', and ended up with: MW-test|root> la /var/run/kresd/ drwxr-x--- 2 root kresd uarch 3 Jul 16 16:03 control -rw-r----- 1 root kresd uarch 10485760 Jul 16 16:08 data.mdb -rw-r----- 1 root kresd uarch 8192 Jul 16 16:03 lock.mdb I don't understand why, but user is still root for both mdb files! Tries some restart operations, but ownership remains root, not to my surprise. And starting krescachegc results in the already reported error messages. Understandable, as krescachegc runs as user kresd and cannot access both files. BUT: If I do run krescachegc as root [1], krescachegc stops complaining. I don't know, if that will be ok, though. [1] command_args="-c -f -r -S -T ${name} -- ${procname} -c ${kresd_rundir} -d ${krescachegc_millis}" Last, but not least, knot-resolver-5.7.3 is out: TIMESTAMP = 1721139599 SHA256 (knot-resolver-5.7.3.tar.xz) = efc6e45ffc5efd98921ea5cd3fece166a1a5ce9eaa12d41b46268964353dbedb SIZE (knot-resolver-5.7.3.tar.xz) = 1930732 Compiles and runs as expected. Regards, Michael
(In reply to Michael Grimm from comment #5) > I don't understand why, but user is still root for both mdb files! I also would like to understand; I'm now running around 20 jails (production), all behaving uneventful as desired In kresd.conf I do have this line, which I start to wonder is the culprit when missing: user('kresd','kresd') And in rc.conf only: krescachegc_enable="YES" kresd_enable="YES" A] is that what you also had? or if not: does that work? B] if that doesn't work immediately; with the kresd_start routine creating the rundir with -m 700, what happens is you delete that entire directory before starting? > If I do run krescachegc as root [1], krescachegc stops complaining. > C] since you currently run as root... would putting below line in rc.conf "solve" this issue for you? kresd_user="root" kresd_group="root"
(In reply to Leo Vandewoestijne from comment #6) As I started testing in a vanilla test jail, I forgot to use my previous kresd.conf, and thus, indeed the following has been the culprit: > In kresd.conf I do have this line, which I start to wonder is the culprit when > missing: > user('kresd','kresd') With that evrything works as expected, kresd and krescachegc. Thanks and sorry for the noise. Regards
Comment on attachment 248987 [details] patch for dns/knot-resolver/files kresd.in and krescachegc.in OK, good to hear. I decline your patch for clarity, however all credit for this improvement goes to you. Thanks for your report and all feedback.
(In reply to Leo Vandewoestijne from comment #8) I do have to thank as well. And FYI: I did close PR 277950
Created attachment 252511 [details] knot-resolver rc + update Same patch, but now including upgrade to 5.7.3 Perfectly passed tests with poudriere and portclippy. @committer, for clarity -and because I cannot set BLOCK/DEPEND on PR's I didn't open- I crosspost the order of execution: step 1: PR 277332: dns/knot3 - add options / - prepare to replace knot3-lib step 2: PR 277540: dns/knot-resolver - fix rc scripts - abandon use of knot3-lib - upgrade to current version step 3: PR 280626: dns/knot3-lib - delete absolete knot3-lib port
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=42b2996954c75b2fdcce7e306dc47a3bbaf551c2 commit 42b2996954c75b2fdcce7e306dc47a3bbaf551c2 Author: Leo Vandewoestijne <freebsd@dns.company> AuthorDate: 2024-08-07 15:37:28 +0000 Commit: Fernando Apesteguía <fernape@FreeBSD.org> CommitDate: 2024-08-08 14:36:09 +0000 dns/knot-resolver: fixing rc scripts krescachegc and kresd * kresd.i lacked activation of defined status_cmd="${name}_status" * dns/knot-resolver/files/krescachegc.in needed full clean-up: * daemon didn't start due to missing '-c <resolver_cache>' * missing 'start', 'stop' and 'status' functionality added PR: 277540 Reported by: trashcan@ellael.org dns/knot-resolver/Makefile | 3 +- dns/knot-resolver/distinfo | 6 ++-- dns/knot-resolver/files/krescachegc.in | 52 ++++++++++++++++++++++++++++++---- dns/knot-resolver/files/kresd.in | 52 ++++++++++++++++++---------------- dns/knot-resolver/pkg-plist | 2 +- 5 files changed, 79 insertions(+), 36 deletions(-)
Committed, Thanks!
Created attachment 252613 [details] Fix dns/knot-resolver/Makefile Here is a 'diff --git' patch. I don't know if this is the right PR to add this patch. Anyway, Leo needs to approve.
(In reply to Michael Grimm from comment #13) Poudriere compiles dns/knot-resolver with this patch, and knot-resolver works as expected