From owner-freebsd-fs@freebsd.org Tue Sep 4 21:10:36 2018 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CEC35FFC0F6; Tue, 4 Sep 2018 21:10:36 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.not-for.work (onlyone.not-for.work [148.251.9.81]) by mx1.freebsd.org (Postfix) with ESMTP id 730CF818B2; Tue, 4 Sep 2018 21:10:36 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:88d0:b252:4399:906d]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.not-for.work (Postfix) with ESMTPSA id 8361FBD8; Wed, 5 Sep 2018 00:10:35 +0300 (MSK) Date: Wed, 5 Sep 2018 00:10:35 +0300 From: Lev Serebryakov Reply-To: Lev Serebryakov Organization: FreeBSD Message-ID: <774228883.20180905001035@serebryakov.spb.ru> To: Conrad Meyer CC: FreeBSD Current , freebsd-fs , Xin LI Subject: Re: newfs silently fails if random is not ready (?) In-Reply-To: References: <609400979.20180904230820@serebryakov.spb.ru> <1942661439.20180904235514@serebryakov.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2018 21:10:37 -0000 Hello Conrad, Wednesday, September 5, 2018, 12:05:43 AM, you wrote: > On Tue, Sep 4, 2018 at 1:55 PM, Lev Serebryakov wrote: >> Tuesday, September 4, 2018, 11:37:59 PM, you wrote: >>> Is newfs tripping on a raise()/abort() in arc4random(3) / >>> getentropy(3)? >> Nope, it is silently does nothing > I think it is tripping on raise/abort() in one of these routines, but > nothing is printing that information. See below. Maybe, it should be fixed? One second after that random is ready to use and newfs works as intended. It is, really, some race between early init script (rc.initdiskless) and kernel. I don't think, that newfs must be killed/aborted in such situation, it could wait! >>> Is your program that runs newfs checking for non-zero >>> exit status? >> It is not "my" program, it is system mdmfs(8), and it checks exit >> statuses, as far as I can see from source code. > Ah, thanks. I missed this. mdmfs(8) has a bug in its run() function. > It treats programs that exit with a signal (KILL, ABRT, ILL, SEGV...) > the same as programs that exit with success. This is a (major) > problem and the reason raise/abort is not visible. And it is another problem. But if it will be fixed, it doesn't help to init system properly in my case, only diagnostic will be better. -- Best regards, Lev mailto:lev@FreeBSD.org