From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/10165 Path: news.gmane.org!not-for-mail From: Natanael Copa Newsgroups: gmane.linux.lib.musl.general Subject: Re: abort() fails to terminate PID 1 process Date: Mon, 20 Jun 2016 12:29:26 +0200 Message-ID: <20160620122926.09440140@ncopa-desktop.alpinelinux.org> References: Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1466418591 21739 80.91.229.3 (20 Jun 2016 10:29:51 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 20 Jun 2016 10:29:51 +0000 (UTC) Cc: musl@lists.openwall.com To: Karl =?ISO-8859-1?B?QvZobG1hcms=?= Original-X-From: musl-return-10178-gllmg-musl=m.gmane.org@lists.openwall.com Mon Jun 20 12:29:50 2016 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1bEwSi-0008Ku-A2 for gllmg-musl@m.gmane.org; Mon, 20 Jun 2016 12:29:48 +0200 Original-Received: (qmail 16376 invoked by uid 550); 20 Jun 2016 10:29:46 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 16355 invoked from network); 20 Jun 2016 10:29:46 -0000 In-Reply-To: X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.28; x86_64-alpine-linux-musl) Xref: news.gmane.org gmane.linux.lib.musl.general:10165 Archived-At: On Sat, 18 Jun 2016 22:32:23 +0200 Karl B=F6hlmark wrote: > Hi! >=20 > After running alpine-linux based docker containers for a while we noticed > some problematic behaviour when one of our services had a memory leak > causing the process to abort. >=20 > Instead of getting abnormal process termination we were seeing the process > hanging at 100% cpu. >=20 > A minimal reproduction of this issue is to run >=20 > #include > int main () > { > abort(); > } >=20 > with "unshare --fork --pid" so that it runs as PID 1 in it's own PID > namespace. >=20 > Would it be reasonable to add a fallback strategy in abort() for > terminating processes when the signals don't have any effect? A workaround is to run your service under a minimalistic init like tini https://github.com/krallin/tini Then your application will no longer run as pid 1. -nc