similar to: [Bug 396] sshd orphans processes when no pty allocated

https://bugzilla.mindrot.org/show_bug.cgi?id=396 --- Comment #23 from Ulrich Sibiller <uli42 at gmx.de> --- I have not tested it but the name of the two options does not seem that it is the exact fix for this problem as this happens when _killing_ the connection, see Descripton. While a timeout might kill the dangling processes it will probably do so after some _time_ not at the time the

http://bugzilla.mindrot.org/show_bug.cgi?id=396 Summary: sshd orphans processes when no pty allocated Product: Portable OpenSSH Version: -current Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: sshd AssignedTo: openssh-unix-dev at mindrot.org ReportedBy:

http://bugzilla.mindrot.org/show_bug.cgi?id=396 ------- Additional Comments From markus at openbsd.org 2003-06-05 00:09 ------- sending signals could be dangerous, depending on the permissions of the sending process, e.g. a root-owned sshd sending to a setuid process. but i'm not sure. we had similar code there before. ------- You are receiving this mail because: ------- You are the

http://bugzilla.mindrot.org/show_bug.cgi?id=396 ------- Additional Comments From djm at mindrot.org 2005-02-14 11:55 ------- Is this not another manifestation of the infamous bug #52? ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.

https://bugzilla.mindrot.org/show_bug.cgi?id=396 Martin d'Anjou <point14 at magma.ca> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |point14 at magma.ca --- Comment #13 from Martin d'Anjou <point14 at magma.ca> 2008-12-13

http://bugzilla.mindrot.org/show_bug.cgi?id=396 ------- Additional Comments From dtucker at zip.com.au 2002-09-12 23:26 ------- Created an attachment (id=145) --> (http://bugzilla.mindrot.org/attachment.cgi?id=145&action=view) Send HUP to sshd child procs on exit ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=396 djm at mindrot.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=396 dtucker at zip.com.au changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |patch ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=396 ------- Additional Comments From dtucker at zip.com.au 2003-05-04 11:14 ------- Does anyone object to this patch? And if not, is it something that should go to OpenBSD? ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.

Hello everyone, I've look at the latest nightly snapshot but I could find this bug is fixed on the source code. Is there any progression to fix that issue. This bug is open for almost 10 years, come on guys :) >List: openssh-unix-dev >Subject: Re: killing remote commands >From: HAUTREUX Matthieu <matthieu.hautreux () cea ! fr> >Date: 2010-10-21

https://bugzilla.mindrot.org/show_bug.cgi?id=396 Tyler Riddle <triddle at gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |triddle at gmail.com --- Comment #20 from Tyler Riddle <triddle at gmail.com> --- I just hit the condition of

https://bugzilla.mindrot.org/show_bug.cgi?id=396 Damien Miller <djm at mindrot.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution|--- |FIXED CC| |djm

https://bugzilla.mindrot.org/show_bug.cgi?id=396 Andrew McNabb <amcnabb at mcnabbs.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |amcnabb at mcnabbs.org --- Comment #16 from Andrew McNabb <amcnabb at mcnabbs.org> 2012-02-10 05:21:40 EST

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

Hi Ulrich, [Reviving an old thread - I owe you an answer :-)] On Thu, 9 Mar 2023 17:02:15 +0000, Ulrich Sibiller via samba <samba at lists.samba.org> wrote: > Martin Schwenke schrieb am 01.03.2023 23:53: > > On Wed, 1 Mar 2023 16:18:58 +0000, Ulrich Sibiller <ulrich.sibiller at atos.net> wrote: > > > which ignores the port and thus matches all connections for

Hello Ralph, Thanks for that hint about case sensitivity's performance penalty. For clarifaction: The user is doing mainly reads, so does the "create" you mention also cover opening/reading files? If only _creation_ of files is suffering from that we probably have some other/further performance issue. We have gpfs, which does not offer a case-insensitive mode, neither does the

Hi Uli, On Wed, 16 Oct 2024 15:18:13 +0000, Ulrich Sibiller <ulrich.sibiller at eviden.com> wrote: > Martin Schwenke schrieb am 16.10.2024 04:33: > > In this old thread, we also discussed problems with ctdb_killtcp. The > > patch series containing the above change also adds a script option to > > enable use of "ss -K" for resetting TCP connections to a

Martin Schwenke schrieb am 01.03.2023 23:53: > Not perfect, but better... Yes, I am quite happy with the ctdb_killtcp. > For ctdb_killtcp, when it was basically rewritten, we considered adding > options for max_attempts, but decided to see if it was foolproof. We > could now add those options. Patches welcome too... I'll have a look. > MonitorTimeoutCount defaults to 20

Martin Schwenke schrieb am 17.10.2024 13:00: >> Thanks! I hope to being able to use a current version soon. > > Of course, I meant the next minor version (e.g. 4.22.x), since none of > this is really bug fixes... Unfortunately I am still not able to run the current version, but for this problem it should not matter because the current code is unchanged in that regard: We are

Hi, In current (6140c3177a0330f42411618c3fca28930ea02a21) samba's ctdb/tools/statd_callout_helper I find this comment: notify) ... # we need these settings to make sure that no tcp connections survive # across a very fast failover/failback #echo 10 > /proc/sys/net/ipv4/tcp_fin_timeout #echo 0 > /proc/sys/net/ipv4/tcp_max_tw_buckets #echo 0 >