On 2018/11/22 21:05, Andreas Kusalananda Kähäri wrote: > On Thu, Nov 22, 2018 at 02:39:54PM +0000, Stuart Henderson wrote: > > > On Sun, 22 Apr 2018 at 16:03:23 +0200, Andreas Kusalananda Kähäri wrote: > > > > I posted about this update in late March when I had issues getting the > > > > sshguard service to properly shut down, but that issue has since been > > > > resolved (rc_stop() needs to send it the HUP signal). > > > > HUP to shutdown?! is there some analysis on this, that's really weird. > > Looking at > > https://bitbucket.org/sshguard/sshguard/src/ff8b525254a6c6e01e0f484cc3feba93e28a326e/src/sshguard.in?at=master&fileviewer=file-view-default > > > The main sshguard utility is a shell script that starts a log "tail" > reader, a log parser, a "blocker" (which I presume decides whether a > behaviour warrants blocking or not) and a firewall-specific backend that > actually does the blocking. These are started in a shell pipeline: > > eval $tailcmd | $libexec/sshg-parser | \ > $libexec/sshg-blocker $flags | ($BACKEND; kill -PIPE $$) > > (the unquoted variable expansions..., I won't comment more on them) > > The bulk of the main shell script is just setting up the values of the > variables used in this pipeline. > > At the start of the script, there's > > trap "trap - TERM && kill 0" INT TERM EXIT > > ... which does my head in a bit. It's *really* easy to start sshguard > and have one of the components of this pipeline not work correctly (it's > usually one and the same, but I forget which one now). This usually > happens when it's started from pkg_scripts at boot (but not when started > manually later for some reason). Sending the main script a HUP was > about the *only* way I could reliably get all components of the pipeline > to exit cleanly. > > I'm assuming that it expects /bin/sh to be bash, and this could be one > of the reasons why it misbehaves under our /bin/sh (I haven't tested > with bash). > > I have only ever looked at the shell script portion of sshguard 2.1.0 > and the BitBucket Git thing I linked to and quoted above may well be > newer than that. I gave up when I couldn't get it to start/shut down > reliably. > > When it *ran*, it worked flawlessly. > > I've been meaning to get back to this to sort it out for OpenBSD, but > have forgotten and have had other things getting in the way.
Thanks - no objection to the update then, but would appreciate a link to the list archive for this (https://marc.info/?l=openbsd-ports&m=154291717732337&w=2) in commit log for the benefit of people looking later :)
