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

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

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 >

Hello, We have a user that switched from Linux to Windows with his engineering software. Previously he was using NFS to access data and there were no performance complaints. Now, with Windows, the same procedures take minutes instead of seconds. I created some log files in Samba 4.10.16-25.el7_9 (recompiled with gpfs support and using the gpfs vfs module) with debuglevel 10 to see if

Hello Ulrich, On 11/10/23 13:47, Ulrich Sibiller via samba wrote: > We have a user that switched from Linux to Windows with his > engineering software. Previously he was using NFS to access data and > there were no performance complaints. > > Now, with Windows, the same procedures take minutes instead of > seconds. the classic workload where Samba performance sucks is when