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
No comments:
Post a Comment