Summary: | dns/knot-resolver: the kresd init script won't stop the service | ||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | Ports & Packages | Reporter: | Chris Hutchinson <portmaster> | ||||||||||||||||
Component: | Individual Port(s) | Assignee: | freebsd-ports-bugs (Nobody) <ports-bugs> | ||||||||||||||||
Status: | Closed DUPLICATE | ||||||||||||||||||
Severity: | Affects Some People | CC: | freebsd, vcunat | ||||||||||||||||
Priority: | --- | Flags: | freebsd:
maintainer-feedback-
freebsd: maintainer-feedback- |
||||||||||||||||
Version: | Latest | ||||||||||||||||||
Hardware: | Any | ||||||||||||||||||
OS: | Any | ||||||||||||||||||
See Also: | https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=257553 | ||||||||||||||||||
Attachments: |
|
Description
Chris Hutchinson
2021-05-28 17:43:46 UTC
This works. But seems kind of awkward: for all in `ps waux | grep kresd | awk '{print $2;}'` do kill -HUP $all done (In reply to Chris Hutchinson from comment #1) I know the problem, but I use it in dedicated jails. But indeed the behaviour is incorrect, and I fail to see what is the cause. And manually I used to do the same command. What about this in files/krescachegc.in for all in `pgrep -x kresd` do kill -HUP $all done and this is files/kresd.in for all in `pgrep -x kres-cache-gc do kill -HUP $all done ...? (In reply to Leo Vandewoestijne from comment #2) kill -HUP doesn't actually kill - I do think we'll need -9 here. (In reply to Leo Vandewoestijne from comment #3) -HUP (HangUP) _should_ be enough. But kresd(8) isn't cleaning up after itself with either -HUP || -9 IOW the pid files are still left within kresd/ && kresd/control I think this is going to be a bit more involved than it initially appeared. Pretty sure it's because its service handling is so intimately tied to serviced. :-( --Chris (In reply to Chris Hutchinson from comment #4) /serviced/systemd/ OK after many iterations of several different possibilities. This is the only way I can guarantee a successful termination of kresd(8) that insures that it also cleans up after itself: for pid in `ps waux | grep kresd | grep daemon | awk '{print $2;}'` do kill -TERM $pid done I created a script in my ~/bin/ folder called kresd-stop: #!/bin/sh - for pid in `ps waux | grep kresd | grep daemon | awk '{print $2;}'` do kill -TERM $pid done exit HTH --Chris Somebody(tm) (not me) should look at the source and try to untangle how they currently try to initiate && terminate kresd(8). To add ifdef(s) for freebsd. So that we can (initi|termin)ate it in a *BSD friendly way. ;-) Maybe this[1] would be of some assistance (untested)? 1) https://github.com/akhilvij/systemd-to-sysvinit-converter --Chris Hello, upstream here.
> kill -HUP doesn't actually kill - I do think we'll need -9 here.
-HUP isn't supported, -TERM is the way (for both kresd and kres-cache-gc). Is that unfriendly for FreeBSD?
pidfiles: we don't use them at all. I'm not familiar with /usr/sbin/daemon (which you use as a wrapper).
--Vladimir
(In reply to Vladimír Čunát from comment #9) > -HUP isn't supported, -TERM is the way (for both kresd and kres-cache-gc). -HUP *does* remove kresd from the process list. So I think we can safely assume it gets killed. BUT I completely agree that -TERM is the correct answer here. daemon(8) appears to me to be unnecessary overhead, and just muddies the water. eg; # ps waux | grep kres root 26098 0.0 0.0 11004 2024 - Is 13:30 0:00.00 daemon: /usr/local/sbin/kresd[26553] (daemon) root 26553 0.0 0.1 140312 40388 - S 13:30 0:46.35 /usr/local/sbin/kresd -c /usr/local/etc/knot-resolver/kr NOTE above that process 26553 is the daemon(8) initiation process. Whereas 26098 is the kresd(8) process itself. So in using daemon(8), we end up with 2 procs/pids. Whereas simply starting kresd(8) alone as a daemon reduces that to the kresd(8) proc/pid (kresd.pid). I'm cobbling up a new rc.d/kresd init script now that currently provides START && STOP. But want to add RESTART to it as well. I'd have already posted it here. But I'm juggling this along side $WORK and all my testing is on a production server that actually depends on kresd already. So testing is a little strained. I should be able to provide something here for further examination within a couple hours. --Chris Created attachment 225535 [details]
dns/knot-resolver: replacement for rc.d/kresd
OK sorry for the delay. Been a real busy day with many
interruptions.
Anyway, the attached proposed rc.d/kresd file, while not
elegant, serves its purpose quite well.
Ideally; to better deal with daemon(8). I'd create a
sup script && install it in ${prefix}/sbin/
That way one can get more finite control over the process
that daemon(8) is launching.
But this gets the job done pretty well, just the same. :-)
--Chris
Created attachment 225536 [details]
dns/knot-resolver: replacement for rc.d/kresd (final version)
Sorry. Attached the wrong file last time.
Created attachment 225548 [details]
dns/knot-resolver: replacement for rc.d/kresd (version 3)
OK I've found the time to add restart.
The attached rc.d/kresd file provides the following:
service (start | stop | restart )
While it's not perfect. I'm a bit strained for time
and this should pretty well cover the needs for the
initialization of kresd -- it WFM. :-)
I'm working in a dirty environment, or I would have
submitted this as a proper git diff. Sorry.
--Chris
Created attachment 225552 [details]
git diff for dns/knot-resolver
OK I used my lunchtime to do this right.
Please find attached a git diff proper for
dns/knot-resolver.
Changes
files/kresd.in
Adds the ability to:
service kresd (start | stop | restart)
That's it. Works as intended for everything
rc.subr is intended to provide.
--Chris
Created attachment 225620 [details]
git diff for dns:/knot-resolver (version 2)
OK after a great deal of additional testing. I
discovered I wasn't sending the process name we're
interested in to syslog(3) -- kresd. The git diff
attached, corrects that.
That's it. I'm done here. I might also send a pull
request upstream for the addition of this to their
source.
Please commit.
--Chris
OK I was going to submit a pull/merge request with upstream. But after filling in all the registration fields, and pressing "register". I'm informed that: There was an error with the reCAPTCHA. Please solve the reCAPTCHA again. However. No reCAPTCHA is ever presented. So upstream is apparently broken. I have a GitLab account and have no problems there. But it's not possible at gitlab.nic.cz. :-( Vladimír? --Chris I'll forward the information to the administrators. If you have a GitHub account, I'd personally try that button for logging via that provider. (In reply to Vladimír Čunát from comment #17) > I'll forward the information to the administrators. Thank you kindly, Vladimír! :-) > If you have a GitHub account, I'd personally try that > button for logging via that provider. Ah, I see. I'm afraid I only have GitLab accounts. Thanks again! :-) --Chris > I was going to submit a pull/merge request with upstream.
The registration problem was worked around within a few hours (reportedly), but I don't really get what you're about to submit. I don't think it makes sense for us (upstream) to include the FreeBSD init scripts, as none of us knows about writing (FreeBSD) init scripts and we can't directly affect their packages/ports anyway.
Maybe it might've made sense in order to share the scripts among other systems, but I don't know if they're really portable and I'm not aware of Knot Resolver packages existing for some such other system anyway.
By the way, finding out PID by a `ps` call feels a bit fragile to me (though I expect it's better to get some improvement than nothing). I assumed that the pidfiles are meant to keep this state, but I don't really know init script stuff...
(In reply to Vladimír Čunát from comment #19) > The registration problem was worked around within a few hours (reportedly), > but I don't really get what you're about to submit. I don't think it makes > sense for us (upstream) to include the FreeBSD init scripts, as none of us > knows about writing (FreeBSD) init scripts and we can't directly affect > their packages/ports anyway. Thanks for your efforts, Vladimír! Sure. Probably better to keep it local (here) to the FreeBSD ports. > By the way, finding out PID by a `ps` call feels a bit fragile to me > (though I expect it's better to get some improvement than nothing). > I assumed that the pidfiles are meant to keep this state, but I don't > really know init script stuff... Wouldn't have been my first choice either. But, given the use of daemon(8). We end up with 2 pids... /var/run/kresd/kresd.pid && /var/run/kresd/control/<procnum>.pid and worse; different versions of knot-resolver result in a differently named kresd subdir. But to my credit, it always works as intended. :-) The _correct_ solution would be to remove systemd, and use proper sysV initialization. Or _add_ it; #ifdef (FreeBSD... But until, or unless... this gets the job done. Thanks again, Vladimír. --Chris Comment on attachment 225620 [details]
git diff for dns:/knot-resolver (version 2)
Spotted an typo at
+kgroup=$name}
I will catch it in a short while, however will decline this patch
(but please don't feel offended; your efforts are much appreciated!).
Created attachment 225993 [details]
knot-resolver fixes and cleanup
`daemon` seems needed as otherwise I can't get it to background,
at least not in a way that I think is decent.
About the most recent patch:
- The printf in the 'for pid loop' was inside the loop, being a bit too verbose.
- The install of the possible missing var dir was inside the if/elif/else loop; and then start still would fail in that particular case.
- I simplified the restart routine but then discovered it all was identical to what was inside start/stop already, and so I don't think a restart routine is needed (as restart will work without having a custom one defined).
- I do share the thoughts about using "ps | grep | etc" for finding pid's.
And do share the view something is better than nothing.
poudriere complained about @sample / .sample
Fixed.
portfmt complained about all sorts of minor things.
Fixed a few.
IMHO this patch should be fine, but gladly welcome any major or nitpick comments.
(In reply to Leo Vandewoestijne from comment #22) No offence taken. :-) -Too verbose? I may have gotten carried away. But trimming a little output/formatting to taste was always available. :-) -error(s)? In my final version, I was unable to produce any testing on 3 different versions of knot-resolver, on 3 different versions of FreeBSD -- not saying your wrong. Just saying my experiences were different. :-) -nit; no restart command. -nit; echo "${name} seems already running.": _should_ read: echo "${name} is already running." || echo "${name} already seems to be running." Hey, you asked. ;-) --Chris Had a thought about the (missing) restart command. At the end of your start command: + else + echo "${name} seems already running." + fi Maybe change it as follows: + else + echo "${name} is already running!" + echo "Restarting ${name}..." + run_rc_command stop + run_rc_command start + echo "${name} restarted." + fi Seems simple, and won't break/harm anything. Yet only adds 4 additional lines. :-) --Chris Created attachment 226234 [details]
knot-resolver final
(In reply to Chris Hutchinson from comment #24) I did applied your grammar pointers. But I did not applied the restart routine, because without a separate restart routine defined the restart parameter would execute stop/start, and so output the very same warnings (but with less code). Further I tested with portlint, poudriere, portfmt and portclippy and made minor changes in order to please them as much as possible. This seems kind of stuck, or at least I can't see the port changing. Anyway, since today's release 5.4.0 it's possible to log directly through the syslog(3) interface. https://knot-resolver.readthedocs.io/en/stable/config-logging-monitoring.html You could e.g. pass an extra configuration file in the service command-line to add such distro-specific settings, similarly to what we do with systemd by default: https://gitlab.nic.cz/knot/knot-resolver/-/blob/v5.4.0/systemd/kresd@.service.in#L15 https://gitlab.nic.cz/knot/knot-resolver/-/blob/v5.4.0/daemon/lua/distro-preconfig.lua.in (In reply to Vladimír Čunát from comment #27) OK, thanks, I've submitted PR 257553 Chris, can you please close this one? Sure. For future ref. You can use the Blocks: field in a new pr(1) to block older/other PRs as required. :-) --Chris *** This bug has been marked as a duplicate of bug 257553 *** |