similar to: sshd signal handling

https://bugzilla.mindrot.org/show_bug.cgi?id=1692 Summary: sshd sometimes dies when sent multiple SIGHUPs in quick succession Product: Portable OpenSSH Version: 5.3p1 Platform: Other URL: https://bugs.launchpad.net/ubuntu/+source/openssh/+bug /497781 OS/Version: Linux Status: NEW

Hi I am just porting ssh-5.2 to my HPUX system. but while I'm doing it, I accidently found a different handling of the sshd for the SIGHUP signal when it is started with a "./sshd_config" and "/sshd_config". The problem is as following: root at sshpa6# uname -a HP-UX sshpa6 B.11.31 U 9000/800 2404418693 unlimited-user license root at sshpa6#

On 21/01/20 8:44 pm, Damien Miller wrote: > On Tue, 21 Jan 2020, Philipp Marek wrote: > >>> This makes me think that the syslog approach is probably the way to go >> >> Yeah, right. >> Another idea is to mirror the current preauth load via setproctitle()... >> That makes that data accessible even without a syscall (at least the >> writing of the

sshd will die from an unhandled SIGALRM if you allow SSH1 connections, ssh in, HUP sshd, and don't ssh in again for KeyRegenerationInterval. The HUP handler calls exec which resets signal handlers but persists alarm timers. Chapter and verse: http://www.opengroup.org/onlinepubs/000095399/functions/alarm.html -- Andrew Gaul http://gaul.org/ -------------- next part -------------- Index:

sshd will die from an unhandled SIGALRM if you allow SSH1 connections, ssh in, HUP sshd, and don't ssh in again for KeyRegenerationInterval. The HUP handler calls exec which resets signal handlers but persists alarm timers. Chapter and verse:

If one is using the pidfile as an indicator of sshd's status, it is possible to kill sshd before the sigterm handler gets installed, since the pidfile is written out before the signal handlers are setup. The solution is to simply write the pidfile after the signal handlers are setup. Here's the patch. Rob --- sshd.c.orig Fri Jun 22 11:16:41 2001 +++ sshd.c Fri Jun 22 11:18:32 2001 @@

On command: #kill -9 `cat /var/run/sshd.pid` sshd leave pid file ! sshd.c code: =============== .... /* * Arrange to restart on SIGHUP. The handler needs * listen_sock. */ signal(SIGHUP, sighup_handler); signal(SIGTERM, sigterm_handler); signal(SIGQUIT, sigterm_handler); .... =============== Missing line is : signal(SIGKILL, sigterm_handler);

http://bugzilla.mindrot.org/show_bug.cgi?id=529 Summary: sshd doesn't work correctly after SIGHUP Product: Portable OpenSSH Version: 3.6p1 Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: sshd AssignedTo: openssh-unix-dev at mindrot.org ReportedBy:

From: Simon Perreault <nomis80 at lqt.ca> > Sure, theoretically it would be possible, but how would you restart this one? > [nomis80 at poste10-153 ~]$ sudo lsof | grep libc | grep init > init 1 root mem REG 253,0 1521500 999437 /lib/tls/libc-2.3.5.so I need to verify the post-install script for the glibc RPM, but I believe it SIGHUPs the process -- and

On 29 July 2014 15:02, Evgeniy Stepanov <eugeni.stepanov at gmail.com> wrote: > You mean replacing SIGUSR1 with SIGHUP in the test case? Weird, I > don't see how they are different. So, AFAIK, they should be identical. But I put some printfs and sleeps around and it wasn't a synchronization issue. My man page says that SIGUSR1 should terminate if there isn't a handler for

I can. I've removed every other compilation flags from clang and even used GCC, with the exact same behaviour. cheers, --renato On 29 July 2014 15:15, Evgeniy Stepanov <eugeni.stepanov at gmail.com> wrote: > OK, we can switch to SIGHUP. Could you please verify that this SIGUSR1 > behavior is not caused by MSan? > > On Tue, Jul 29, 2014 at 6:09 PM, Renato Golin

Hi, I am seeing a problem where in sshd gets terminated by SIGALRM. sshd was listening on the socket and was not restarted. I saw a recent bug fix in openBSD openssh CVS which mentions: Clear alarm() before restarting sshd on SIGHUP. Without this, if there's a SIGALRM pending (for SSH1 key regeneration) when sshd is SIGHUP'ed, the newly exec'ed sshd will get the SIGALRM and

http://bugzilla.mindrot.org/show_bug.cgi?id=271 Summary: SSHD should unblock SIGCHLD - POSIX signal blocks survive exec() Product: Portable OpenSSH Version: -current Platform: Other OS/Version: other Status: NEW Severity: enhancement Priority: P2 Component: sshd AssignedTo:

Currently, on linux sshd attempts to remove itself from the influence of oom-killer by modifying the oom_adj parameter for itself in proc to -17. This is controlled via two functions; oom_adjust_setup() and oom_adjust_restore(). Setup saves the old score (typically zero on initialization) and sets sshd to -17 whilst oom_adjust_restore places the saved value from initialization back into the

Richard Schilling wrote: Do you notice wether or not it takes a certain number of connections for the bug to show up? I'm not seeing this problem with just a few people connecting via sftp (about 2-4 times per week). --Richard On 2003.06.13 22:36 Scott Lambert wrote: > We have been having a problem with sshd on our shell server. > > This has been happening since March 4,

https://bugzilla.mindrot.org/show_bug.cgi?id=2156 Bug ID: 2156 Summary: Fix oom_adj on Linux after sshd reload Product: Portable OpenSSH Version: 6.2p1 Hardware: All OS: Linux Status: NEW Severity: normal Priority: P5 Component: sshd Assignee: unassigned-bugs at mindrot.org

http://bugzilla.mindrot.org/show_bug.cgi?id=858 Summary: Grammar bug in sshd(8) Product: Portable OpenSSH Version: 3.8.1p1 Platform: Other URL: http://bugs.debian.org/238753 OS/Version: Linux Status: NEW Severity: trivial Priority: P2 Component: Documentation AssignedTo: openssh-bugs

Hi, If anyone has managed to get sshd to run as a subsystem in the System Resource Controller under AIX 4.3.3 (a la mkssys), then please let me know how you did it... I can mkssys and startsrc it, but it dies immediately, leaving a child sshd running with another PID than startsrc reported, and lssrc reports sshd inoperative. Is sshd a process that should stay in foreground, not forking? Or does

https://bugzilla.mindrot.org/show_bug.cgi?id=396 Marc Herbert <marc.herbert+mindrot at gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |marc.herbert+mindrot at gmail. | |com --- Comment #14

https://bugzilla.mindrot.org/show_bug.cgi?id=2263 Bug ID: 2263 Summary: sshd privsep monitor process doesn't handle SIGXFSZ signal Product: Portable OpenSSH Version: 6.6p1 Hardware: All OS: Linux Status: NEW Severity: normal Priority: P5 Component: sshd