From nobody Thu Dec 9 12:03:23 2021 X-Original-To: freebsd-stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 3218E18DE646 for ; Thu, 9 Dec 2021 12:09:19 +0000 (UTC) (envelope-from pmc@citylink.dinoex.sub.org) Received: from uucp.dinoex.org (uucp.dinoex.org [IPv6:2a0b:f840::12]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "uucp.dinoex.sub.de", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J8tB702Xgz4R1S for ; Thu, 9 Dec 2021 12:09:18 +0000 (UTC) (envelope-from pmc@citylink.dinoex.sub.org) Received: from uucp.dinoex.sub.de (uucp.dinoex.org [185.220.148.12]) by uucp.dinoex.org (8.17.1/8.17.1) with ESMTPS id 1B9C94i4035985 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 9 Dec 2021 13:09:05 +0100 (CET) (envelope-from pmc@citylink.dinoex.sub.org) X-Authentication-Warning: uucp.dinoex.org: Host uucp.dinoex.org [185.220.148.12] claimed to be uucp.dinoex.sub.de Received: (from uucp@localhost) by uucp.dinoex.sub.de (8.17.1/8.17.1/Submit) with UUCP id 1B9C94R5035984; Thu, 9 Dec 2021 13:09:04 +0100 (CET) (envelope-from pmc@citylink.dinoex.sub.org) Received: from gate.intra.daemon.contact (gate-e [192.168.98.2]) by citylink.dinoex.sub.de (8.16.1/8.16.1) with ESMTP id 1B9C4dDk049475; Thu, 9 Dec 2021 13:04:39 +0100 (CET) (envelope-from peter@gate.intra.daemon.contact) Received: from gate.intra.daemon.contact (gate-e [192.168.98.2]) by gate.intra.daemon.contact (8.16.1/8.16.1) with ESMTPS id 1B9C3NMH048708 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 9 Dec 2021 13:03:23 +0100 (CET) (envelope-from peter@gate.intra.daemon.contact) Received: (from peter@localhost) by gate.intra.daemon.contact (8.16.1/8.16.1/Submit) id 1B9C3NYj048707; Thu, 9 Dec 2021 13:03:23 +0100 (CET) (envelope-from peter) Date: Thu, 9 Dec 2021 13:03:23 +0100 From: Peter To: Eugene Grosbein Cc: Peter , freebsd-stable@freebsd.org Subject: Re: 12.3: "swapon -a" crashes the system Message-ID: References: List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Milter: Spamilter (Reciever: uucp.dinoex.sub.de; Sender-ip: 185.220.148.12; Sender-helo: uucp.dinoex.sub.de;) X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (uucp.dinoex.org [185.220.148.12]); Thu, 09 Dec 2021 13:09:07 +0100 (CET) X-Rspamd-Queue-Id: 4J8tB702Xgz4R1S X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Thu, Dec 09, 2021 at 02:35:55PM +0700, Eugene Grosbein wrote: ! 09.12.2021 13:11, Peter wrote: ! ! > if you run out of swapspace and you think you might just create ! > some extra devices and add them to /etc/fstab and then run "swapon -a" ! > to enable them, don't do that. ! > ! > The result might look like this: ! > kernel: pid 12296 (daemon), jid 5, uid 5100: exited on signal 10 (core dumped) ! > kernel: pid 17717 (ruby27), jid 5, uid 5100: exited on signal 6 (core dumped) ! > kernel: pid 14938 (daemon), jid 10, uid 5100: exited on signal 10 (core dumped) ! > kernel: pid 19184 (ruby27), jid 10, uid 5100: exited on signal 11 (core dumped) ! > kernel: pid 19182 (ruby27), jid 10, uid 5100: exited on signal 10 (core dumped) ! > ... ! > with a subsequent kernel crash. ! > ! > In my case I did run out of swapspace despite proper sizing, because ! > of unbalanced numa-domains. (Each of them may hit free_target on their ! > own behalf, and then start paging.) ! > ! > So I did as described above, but I added them with the "late" option, ! > and then did run "swapon -a", which did not even add them - but ! > nevertheless produced the crash. The processes that do coredump might ! > be those that are fully swapped out? ! ! Did you try using ZFS-backed files or devices for swap? If so, this is somewhat expected. Hi Eugene, that's a negative: # cat /etc/fstab /dev/ada3p3 / ufs rw 1 1 /dev/ada3p4 /usr ufs rw 1 2 /dev/ada3p5 /var ufs rw 1 2 proc /proc procfs rw 0 0 /dev/ada1p2.eli none swap sw,trimonce 0 0 /dev/ada3p2.eli none swap sw,trimonce,late 0 0 /dev/ada1p10.eli none swap sw,trimonce,late 0 0 /dev/ada3p10.eli none swap sw,trimonce,late 0 0 ... And it happened two times: first when I ran into exhaustion and found some space on a spinning to quickly add. And second after I had figured out the numa matter, reassessed my calculations, and added proper SSD space. cheerio, PMc