From owner-freebsd-hackers@freebsd.org Thu Jan 28 13:49:18 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 44E71A6F4BD for ; Thu, 28 Jan 2016 13:49:18 +0000 (UTC) (envelope-from araujobsdport@gmail.com) Received: from mail-ob0-x22b.google.com (mail-ob0-x22b.google.com [IPv6:2607:f8b0:4003:c01::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 042EC1AF0; Thu, 28 Jan 2016 13:49:18 +0000 (UTC) (envelope-from araujobsdport@gmail.com) Received: by mail-ob0-x22b.google.com with SMTP id is5so35558023obc.0; Thu, 28 Jan 2016 05:49:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=/KY22Ez7U/CGMOvf11mXaGwSPxVO4MegYqlFV6MU5e8=; b=TBFeWqSQO5a1aE9SsQnAwhNxR0ZhRLqAp4N+Irl9DuSUAGV79MgpY/1+mKxSx+WY+c LIZz7wPk5xaEk+g/JnerddCJcUrr7NayvQ0K81aiYD+1V8emOTMkb4MqU8s7PH7w5Z75 mZ2BI/BC26zFK4nA+rVNRGjYp6lHpDOsqS/7ZbxckhrDzYtHRRk32qhCKkh0sClniPE+ 3WDwO+LWk0EhCNPZ4BiazRWOuoWOqhthe0knglwjsCYlo8UMMBD4J/VQpslqnhE80Ehe knilgS70mlbJSHshfXRnHTXPy3w0/wprkcWykseto8HyPCEiHBuRwLIHy9Okf5jqZd1f n2Yg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=/KY22Ez7U/CGMOvf11mXaGwSPxVO4MegYqlFV6MU5e8=; b=E55ooPE0wj5ygdzV6pDnrjWzDokAeQWBIRjSHy5uUiv490Tx27GVM9wmkkdz+EXCF4 acFmM8D3yf47oQOM0VhQ9PC2uO77vl+Gqj79X8zJJHllE0kK6twDj6r32ffvvyKhXFrQ jgXm31BnsXcPr/j6Oekg8eAac91d6NnKhCmDtIydHl/AnnOsUMmirqfbH4VPwPcIsq2E i9I5UZMed4+ptmUWiAJHOkv9RhVpfzDYBKuZUqxZbqT6F0AW7nVX8vMZfM6QoYkAC//g 2G0SGDIoa7kw/X+GMGdgzUHEP/xVn5XIluk35lTH3SfPqYygu2qyEpri/+i/2PG8ISry wzdA== X-Gm-Message-State: AG10YOS4zL7yztd41XkAqy6VwO3Vuv1aVdueaUN7i1QV53l66u+jstqUe02zvx2jOgVB5Sx+i8qObws6VItNtw== MIME-Version: 1.0 X-Received: by 10.182.133.37 with SMTP id oz5mr2285165obb.16.1453988957294; Thu, 28 Jan 2016 05:49:17 -0800 (PST) Received: by 10.182.5.138 with HTTP; Thu, 28 Jan 2016 05:49:17 -0800 (PST) Received: by 10.182.5.138 with HTTP; Thu, 28 Jan 2016 05:49:17 -0800 (PST) Reply-To: araujo@FreeBSD.org In-Reply-To: <56AA11EA.1060903@grosbein.net> References: <56AA11EA.1060903@grosbein.net> Date: Thu, 28 Jan 2016 21:49:17 +0800 Message-ID: Subject: Re: syslogd(8) with OOM Killer protection From: Marcelo Araujo To: Eugene Grosbein Cc: Marcelo Araujo , Adrian Chadd , "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jan 2016 13:49:18 -0000 In my research, I might be wrong, there is no clean way to make such protection without intrusive code in every each deamon. I'm still checking!! On Jan 28, 2016 9:05 PM, "Eugene Grosbein" wrote: > On 27.01.2016 13:32, Adrian Chadd wrote: > > I like it,how's it not done via some command line tool that we can run > > any tool with? > > I've already responded to such idea in a comment to my original PR > and like to repeat it here. IMHO, it is nearly impossible to correctly > implement > such protection for arbitrary daemonizing service by means of rc.subr, > without modifications of service source code. Currently. > > We do have protect(1) utility but it only can protect single process it > starts or > all current/future children of started process and for daemons both cases > are wrong: > > - protection of single process is meaningless because it forks to become > daemon and that ceases protection; > - protection of all future children is dangerous for daemons capable of > running arbitrary subprocesses like syslogd can with "vertical bar" syntax > of syslog.conf(5) as those future children may be "runaway" memory hogs. > > Perhaps, we could have kernel facility that keeps decreasing counter of > forks > and ceases protection of children when counter reaches zero level. > Then teach protect(1) to (re-)set counter value and make rc.subr use it. > >