On Wed, December 5, 2018 4:37 pm, Markus Lude wrote: > 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 >
The init process send HUP. If HUP means to shutdown, it's not going to work. Spampd had a similar problem and had to do the right thing on SIGHUP. On Wed, December 5, 2018 4:37 pm, Markus Lude wrote: > 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 > The init process send HUP. If HUP means to shutdown, it's not going to work. Spampd had a similar problem and had to do the right thing on SIGHUP. On Wed, December 5, 2018 4:37 pm, Markus Lude wrote: > 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 > The init process sends a HUP. If HUP means to shutdown, it's not going to work. Spampd had a similar problem and had to do the right thing on SIGHUP. https://marc.info/?l=openbsd-ports&m=153513465119913&w=2
