From owner-freebsd-jail@freebsd.org Sun Jul 28 21:56:44 2019 Return-Path: Delivered-To: freebsd-jail@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 08CDFB5FDA for ; Sun, 28 Jul 2019 21:56:44 +0000 (UTC) (envelope-from crest@rlwinm.de) Received: from mail.rlwinm.de (mail.rlwinm.de [IPv6:2a01:4f8:171:f902::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 519A6814A0 for ; Sun, 28 Jul 2019 21:56:43 +0000 (UTC) (envelope-from crest@rlwinm.de) Received: from hexe.rlwinm.de (200116b8649b8400feaa14fffe7af214.dip.versatel-1u1.de [IPv6:2001:16b8:649b:8400:feaa:14ff:fe7a:f214]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.rlwinm.de (Postfix) with ESMTPSA id 3091717E20 for ; Sun, 28 Jul 2019 21:56:40 +0000 (UTC) Subject: Re: jailed services dying To: freebsd-jail@freebsd.org References: From: Jan Bramkamp Message-ID: <4fd8eb8a-2e0b-8714-c51a-418e36b5226a@rlwinm.de> Date: Sun, 28 Jul 2019 23:56:37 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Rspamd-Queue-Id: 519A6814A0 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of crest@rlwinm.de designates 2a01:4f8:171:f902::5 as permitted sender) smtp.mailfrom=crest@rlwinm.de X-Spamd-Result: default: False [-3.19 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; NEURAL_HAM_MEDIUM(-0.95)[-0.952,0]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-jail@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; DMARC_NA(0.00)[rlwinm.de]; MX_GOOD(-0.01)[mail.rlwinm.de]; NEURAL_HAM_SHORT(-0.18)[-0.179,0]; IP_SCORE(-0.75)[ipnet: 2a01:4f8::/29(-1.93), asn: 24940(-1.82), country: DE(-0.01)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/29, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-jail@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion about FreeBSD jail\(8\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jul 2019 21:56:44 -0000 On 26.07.19 23:40, David Mehler wrote: > Hello, > > I've got multiple service jails all on a single vps. One is a webserver > running apache 2.4 with php 7.3, the other is a mail server, a > complete virtual mail hosting > setup with Postfix, Dovecot, Rspamd, the other is a database server > running mysql, and I'm wanting to get shared > calendars in it in another setup running davical. I appear to be > having a problem where ocationally a > jail service shuts down, for example the database, which shuts > everything else down because no service can access it, or the rspamd > in the mail jail shuts down. These are all > on a single vps, a dual core I think, 4GB of ram, I'm wondering if i'm > hitting a resource bottleneck and if so how to determine it and to > limit the specific jail factor that is causing the issue? > > Any suggestions appreciated. > By default jails die with their last process. If you are running lightweight jails with just a single service inside them an the service dies for any reason the jail is destroyed as well. You can mark the jails as persistent to keep them around, but it wouldn't solve your real problem. Do you still have the /var/log/messages from around the time of the failure? As Allan Jude already mentions waking the OOM killer would be one possible explanation for the demise of your jails and I can attest from painful experience that the OOM killer has an uncanny knack for finding important processes e.g. the PostgreSQL or Postfix master processes.