On Wed, Dec 05, 2018 at 12:21:33AM +0100, Andreas Kusalananda Khri wrote: > On Fri, Nov 23, 2018 at 03:36:09PM +0000, Stuart Henderson wrote: > > 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. > > This has now been resolved. > (but startup remains an issue, see end) > > > > > > > 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 :) > > Attached is a port of sshguard-2.2.0 which appears to work, sort of. It > does not start at boot when started from pkg_scripts. It *does* start > reliably when started manually with "rcctl start sshguard" and it shuts > down reliably both at system shutdown and manually (and in-between, it > runs well).
Similar happens with the in-tree version sshguard-1.5p6 on 6.4-stable. sshguard _does_ start (as noticed in the log file), but terminates shortly after: shortly after reboot: Dec 5 22:30:14 myhost sshd[33894]: Server listening on 0.0.0.0 port 22. Dec 5 22:30:14 myhost sshd[33894]: Server listening on :: port 22. Dec 5 22:30:15 myhost sshguard[5454]: Started successfully [(a,p,s)=(40, 420, 1200)], now ready to scan. Dec 5 22:30:15 myhost sshd[25608]: Received disconnect from 222.87.49.93 port 27657:11: Bye Bye [preauth] Dec 5 22:30:15 myhost sshd[25608]: Disconnected from 222.87.49.93 port 27657 [preauth] Dec 5 22:30:16 myhost sshguard[5454]: Got exit signal, flushing blocked addresses and exiting... If started manually, it keeps running. > Any help with possible diagnoses of the startup problem would be > helpful. I haven't found any other port that starts a shell script as a > daemon, but I have only looked for "/bin/sh" in the rc scripts for that. Regards Markus
