search for: reaps

Hi Tom and all, I started to play a bit with the AutoBL action on a CentOS 6 box and ran into the following problems: 1) The action.AutoBL doesn''t work for me until I patch it like so: --- /usr/share/shorewall/action.AutoBL.orig 2013-10-01 00:59:42.000000000 +0200 +++ /usr/share/shorewall/action.AutoBL 2013-10-07 14:44:31.530841099 +0200 @@ -22,6 +22,9 @@ DEFAULTS

Commit-ID: ed1a1311732c764495a5ec26bfdcac34ea6dce1b Gitweb: http://git.kernel.org/?p=libs/klibc/klibc.git;a=commit;h=ed1a1311732c764495a5ec26bfdcac34ea6dce1b Author: Herbert Xu <herbert at gondor.apana.org.au> AuthorDate: Mon, 26 Mar 2018 23:55:50 +0800 Committer: Ben Hutchings <ben at decadent.org.uk> CommitDate: Fri, 25 Jan 2019 02:57:21 +0000 [klibc] eval: Reap zombies

Commit-ID: a33ea92e57007317a5c406626441029899e164e0 Gitweb: http://git.kernel.org/?p=libs/klibc/klibc.git;a=commit;h=a33ea92e57007317a5c406626441029899e164e0 Author: Herbert Xu <herbert at gondor.apana.org.au> AuthorDate: Mon, 26 Mar 2018 23:55:50 +0800 Committer: Ben Hutchings <ben at decadent.org.uk> CommitDate: Sat, 28 Mar 2020 21:42:54 +0000 [klibc] dash: eval: Reap

Hi, For this issue I had initial discussion thread before, more detail, please see : http://lists.xensource.com/archives/html/xen-devel/2010-04/msg01140.html. I write a new patch for this issue, which modified qemu code. So Ian, could you take a look this patch,too. thanks, James (Song Wei) Signed-off-by: James ( Song Wei ) <jsong@novell.com> diff -r efa1b905d893

On Sat 18-06-16 03:09:02, Michael S. Tsirkin wrote: > On Fri, Jun 17, 2016 at 11:00:17AM +0200, Michal Hocko wrote: [...] > > It seems that vhost usage would suffer from this problem because > > it reads from the userspace to get (status) flags and makes some > > decisions based on the read value. I do not understand the code so I > > couldn't evaluate whether that

On Sat 18-06-16 03:09:02, Michael S. Tsirkin wrote: > On Fri, Jun 17, 2016 at 11:00:17AM +0200, Michal Hocko wrote: [...] > > It seems that vhost usage would suffer from this problem because > > it reads from the userspace to get (status) flags and makes some > > decisions based on the read value. I do not understand the code so I > > couldn't evaluate whether that

Our Mephisto install kills Mongrels and causes Apache to pound the CPU. This started when we moved to Apache+mod_proxy_balancer+Mongrel. Here''s what we know: The following things are working OK, except when used in the combination listed above: mongrel, mongrel_rails, MySQL, Apache, mod_proxy_balancer. We believe these are all OK because we moved five other Rails apps to this

On Mon, Jan 21, 2013 at 11:28 AM, Eric Wong <normalperson at yhbt.net> wrote: > Charles Hornberger <charles.hornberger at gmail.com> wrote: >> Hi! >> >> I recently noticed this error message when restarting unicorn after a >> code deployment (and I don''t think I recall having seen it before): >> >> I, [2013-01-18T17:54:21.502554 #59285]

I''m having trouble building a package (named reap) under R1.2.1 Windows2000. I successfully ran d:\R\src\library rcmd check reap but when I run d:\R\src\library rcmd build reap I get the message: Please set TMPDIR to a valid temporary directory I''ve tried setting TMPDIR to d:/temp via: 1) My Computer properties environment variables, 2) at the command line, 3) in Rprofile, and

https://bugzilla.mindrot.org/show_bug.cgi?id=2646 Bug ID: 2646 Summary: zombie processes when using privilege separation Product: Portable OpenSSH Version: 7.2p2 Hardware: ix86 OS: Linux Status: NEW Severity: minor Priority: P5 Component: sshd Assignee: unassigned-bugs at

Hi, We''re using unicorn as a Rails server on Solaris, and it''s been running great for several months. We''ve recently been having a few problems and I''m at a loss what might cause it. A number of times in the past few days, our unicorn slaves keep timing out & the master keeps restarting them. unicorn.log looks something like : E,

Pardon me for a long detailed post but this looks pretty serious. The bottom line is that, when I attempt to shut down or reboot my simple xen-2.0.7 server running FC3 with two domUs, shutting down xendomains appears to send python into an infinite loop. This may be due to a serious misconfiguration on my part but it is certainly a big problem. If we shutdown the domUs manually first, the

Hello, syzbot found the following crash on: HEAD commit: 6d028043 Add linux-next specific files for 20190830 git tree: linux-next console output: https://syzkaller.appspot.com/x/log.txt?x=16cbf22a600000 kernel config: https://syzkaller.appspot.com/x/.config?x=82a6bec43ab0cb69 dashboard link: https://syzkaller.appspot.com/bug?extid=aaedc50d99a03250fe1f compiler: gcc (GCC) 9.0.0

It appears that openssh has inherited the dos attack that ssh is susceptible to. This has been discussed on Bugtraq (see http://securityportal.com/list-archive/bugtraq/1999/Sep/0124.html for the thread). There does not appear to be an official for ssh. Attached below is a simple, proof of concept, patch that adds a MaxConnections to sshd_config that sets the maximum number of simultaneous

From: Michal Hocko <mhocko at suse.com> vhost driver relies on copy_from_user/get_user from a kernel thread. This makes it impossible to reap the memory of an oom victim which shares mm with the vhost kernel thread because it could see a zero page unexpectedly and theoretically make an incorrect decision visible outside of the killed task context. Make sure that each place which can read

From: Michal Hocko <mhocko at suse.com> vhost driver relies on copy_from_user/get_user from a kernel thread. This makes it impossible to reap the memory of an oom victim which shares mm with the vhost kernel thread because it could see a zero page unexpectedly and theoretically make an incorrect decision visible outside of the killed task context. Make sure that each place which can read

We have been researching stuck zombie processes in our libvirt lxc containers. What we found was: 1) Each zombie’s parent was pid 1. init which symlinks to systemd. 2) In some cases, the zombies were launched by systemd, in others the zombie was inherited. 3) While the child is in the zombie state, the parent process (systemd) /proc/1/status shows no pending signals. 4) Attaching gdb to

On Fri, Sep 08, 2023 at 08:44:45AM -0600, Jens Axboe wrote: > On 9/8/23 8:34 AM, Ming Lei wrote: > > On Fri, Sep 08, 2023 at 07:49:53AM -0600, Jens Axboe wrote: > >> On 9/8/23 3:30 AM, Ming Lei wrote: > >>> diff --git a/io_uring/io_uring.c b/io_uring/io_uring.c > >>> index ad636954abae..95a3d31a1ef1 100644 > >>> --- a/io_uring/io_uring.c >

On Fri, Sep 08, 2023 at 08:44:45AM -0600, Jens Axboe wrote: > On 9/8/23 8:34 AM, Ming Lei wrote: > > On Fri, Sep 08, 2023 at 07:49:53AM -0600, Jens Axboe wrote: > >> On 9/8/23 3:30 AM, Ming Lei wrote: > >>> diff --git a/io_uring/io_uring.c b/io_uring/io_uring.c > >>> index ad636954abae..95a3d31a1ef1 100644 > >>> --- a/io_uring/io_uring.c >

On Fri, Jun 17, 2016 at 11:00:17AM +0200, Michal Hocko wrote: > From: Michal Hocko <mhocko at suse.com> > > vhost driver relies on copy_from_user/get_user from a kernel thread. > This makes it impossible to reap the memory of an oom victim which > shares mm with the vhost kernel thread because it could see a zero > page unexpectedly and theoretically make an incorrect