Menu
▾
▴
sshguard-users
|
[Sshguard-users] Spurious sshguard shutdowns at boot time with
"sshguard[#]: Got exit signal" logged
From: Richard J. <rjt...@sa...> - 2015-02-16 00:37:59
|
On OpenBSD 5.6, I'm seeing sshguard 1.5.0 stopping nearly immediately upon start at boot time. Typical log entries: Feb 15 16:17:46 host sshguard[765]: Started successfully [(a,p,s)=(40, 420, 1200)], now ready to scan. Feb 15 16:17:47 host sshguard[765]: Got exit signal, flushing blocked addresses and exiting... And sshguard is indeed no longer running. A later manual start of sshguard succeeds. This matches with reported 2012 FreeBSD experience: https://forums.freebsd.org/threads/at-boot-rc-script-runs-but-service-immediately-exits.29623/ However, in my case, even putting in a 60 second delay on the start of sshguard is not enough for sshguard to remain running on the system I'm using for testing. The start is delayed, but then sshguard quits 1-2 seconds later with the 'Go exit signal' message showing in the log. I do not know at present whether there's actually an exit signal sent/received, or whether that message is triggered by something else. Is this known and fixed yet in the dev repository, or has the cause not yet been run down? Richard ------- /etc/rc.d/sshguard: ------- #!/bin/sh # # $OpenBSD: sshguard.rc,v 1.1 2011/03/07 17:44:16 rpointel Exp $ daemon="/usr/local/sbin/sshguard" daemon_flags="-l /var/log/authlog" . /etc/rc.d/rc.subr rc_bg=YES rc_reload=NO rc_cmd $1 ------- |
|
From: Richard J. <rjt...@sa...> - 2015-02-16 02:12:43
|
On Sun, Feb 15, 2015 at 05:19:51PM -0700, Richard Johnson wrote:
> On OpenBSD 5.6, I'm seeing sshguard 1.5.0 stopping nearly immediately upon
> start at boot time. Typical log entries:
>
> Feb 15 16:17:46 host sshguard[765]: Started successfully [(a,p,s)=(40, 420, 1200)], now ready to scan.
> Feb 15 16:17:47 host sshguard[765]: Got exit signal, flushing blocked addresses and exiting...
>
> And sshguard is indeed no longer running. A later manual start of sshguard
> succeeds.
sshguard.c includes SIGHUP in its signals upon which to terminate.
The rc.d startup of sshguard at boot on OpenBSD (and FreeBSD) apparently
comes with a HUP. Sheer guessing here, but this may be because sshguard
has the log file open at the time an initial newsyslog run occurs.
Here's a quick workaround that'll hopefully hold me until there's more time
for reading code and figuring out how to avoid HUPing sshguard at boot
time. It effectively ignores SIGHUP. Confirmed that on OpenBSD 5.6 stable
sshguard is still shut down cleanly at reboot time, as well as stops and
starts fine via /etc/rc.d/sshguard stop|start|restart.
=======
--- src/sshguard.c.orig Wed Feb 9 05:01:47 2011
+++ src/sshguard.c Sun Feb 15 18:30:59 2015
@@ -200,7 +200,6 @@
/* termination signals */
signal(SIGTERM, sigfin_handler);
- signal(SIGHUP, sigfin_handler);
signal(SIGINT, sigfin_handler);
/* load blacklisted addresses and block them (if requested) */
=======
Richard
|
|
From: Kevin Z. <kev...@gm...> - 2015-02-16 03:30:45
|
Hi Richard, Thanks for looking into this issue. On 02/15/2015 20:12, Richard Johnson wrote: > sshguard.c includes SIGHUP in its signals upon which to terminate. > > The rc.d startup of sshguard at boot on OpenBSD (and FreeBSD) apparently > comes with a HUP. Sheer guessing here, but this may be because sshguard > has the log file open at the time an initial newsyslog run occurs. I'm running FreeBSD, but I don't start SSHGuard using 'rc.d' since I'm starting a development version manually every boot. I'm not sure why SIGHUP is being sent. I'll look around... > Here's a quick workaround that'll hopefully hold me until there's more time > for reading code and figuring out how to avoid HUPing sshguard at boot > time. It effectively ignores SIGHUP. Confirmed that on OpenBSD 5.6 stable > sshguard is still shut down cleanly at reboot time, as well as stops and > starts fine via /etc/rc.d/sshguard stop|start|restart. > > ======= > --- src/sshguard.c.orig Wed Feb 9 05:01:47 2011 > +++ src/sshguard.c Sun Feb 15 18:30:59 2015 > @@ -200,7 +200,6 @@ > > /* termination signals */ > signal(SIGTERM, sigfin_handler); > - signal(SIGHUP, sigfin_handler); > signal(SIGINT, sigfin_handler); > > /* load blacklisted addresses and block them (if requested) */ Doesn't the default SIGHUP handler terminate the process? Thanks, Kevin Zheng -- Kevin Zheng kev...@gm... | ke...@kd... | PGP: 0xC22E1090 |
|
From: Richard J. <rjt...@sa...> - 2015-02-16 05:29:00
|
On Sun, Feb 15, 2015 at 09:29:28PM -0600, Kevin Zheng wrote: > Doesn't the default SIGHUP handler terminate the process? Per signal(3) man page, the SIGHUP default when SIG_DFL is requested is process termination. My naive understanding is that SIG_DFL has to be specifically requested in a signal() call, however. Not specifying SIGHUP in any signal() call might as a side effect set the signal mask to block SIGHUP. But my experience here is way back in time, so I'm not sure any more. What I see in practice is SIGHUP having no effect (presumably at boot, but very definitely when sent manually) after I remove the signal() call setting its handler. Hmm, for the nonce, it might be better to explicitly set the handler to SIG_IGN than just leave it out. I still want to understand why the SIGHUP is being sent, and then perhaps see about not sending it if that makes sense. Richard |
Thanks for helping keep SourceForge clean.
X