From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 0F7271381DF for ; Tue, 16 Feb 2016 19:33:15 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 4589421C051; Tue, 16 Feb 2016 19:32:59 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 6867621C023 for ; Tue, 16 Feb 2016 19:32:53 +0000 (UTC) Received: from [IPv6:2a02:8109:a640:180c:5ee0:c5ff:fe8e:77db] (unknown [IPv6:2a02:8109:a640:180c:5ee0:c5ff:fe8e:77db]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: patrick) by smtp.gentoo.org (Postfix) with ESMTPSA id 232EB340C21 for ; Tue, 16 Feb 2016 19:32:46 +0000 (UTC) Subject: Re: [gentoo-dev] rfc: Does OpenRC really need mount-ro To: gentoo-dev@lists.gentoo.org References: <20160216180533.GB1450@whubbs1.gaikai.biz> From: Patrick Lauer X-Enigmail-Draft-Status: N1110 Message-ID: <56C3792A.3010602@gentoo.org> Date: Tue, 16 Feb 2016 20:31:54 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 In-Reply-To: <20160216180533.GB1450@whubbs1.gaikai.biz> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Archives-Salt: 316e5341-b0b4-4581-9842-cbcedaa9ce72 X-Archives-Hash: ecb8ba62805c6a75434550ded1dc065f On 02/16/2016 07:05 PM, William Hubbs wrote: > All, > > I have a bug that points out a significant issue with > /etc/init.d/mount-ro in OpenRC. > > Apparently, there are issues that cause it to not work properly for file > systems which happen to be pre-mounted from an initramfs [1]. I don't understand how this fails, how does mounting from the initramfs cause issues? The failure message comes from rc-mount.sh when the list of PIDs using a mountpoint includes "$$" which is shell shorthand for self. How can the current shell claim to be using /usr when it is a shell that only has dependencies in $LIBDIR ? As far as I can tell the code at this point calls fuser -k ${list of pids}, and fuser outputs all PIDs that still use it. I don't see how $$ can end up in there ... > > This service only exists in the Linux world; there is no equivalent in > OpenRC for any other operating systems we support. > > The reason it exists is very vague to me; I think it has something to do > with claims of data loss in the past. Yes, if you just shut down without unmounting file systems - (1) you may throw away data in the FS cache that hasn't ended up on disk yet (2) the filesystem has no chance to mark itself cleanly unmounted, so you will trigger journal replay or fsck or equivalent on boot That's why sysvinit had a random "sleep(1)" in the halt and "sleep(2)" in the reboot function, to give computers more of a chance to shutdown and reboot sanely. The changes in sysvinit-2.88-r8 and later add the "-n" option: -n Don't sync before reboot or halt. Note that the kernel and storage drivers may still sync. This was added *because* we can guarantee that filesystems are consistent enough with mount-ro. If you wish to remove it you need to reconsider all these little details ... > > I'm asking for more specific information, and if there is none, due to > the bug I lincluded in this message, I am considering removing this > service in 0.21 since I can't find an equivalent anywhere else. Please don't just remove things you don't understand. > > Thanks, > > William > > [1] https://bugs.gentoo.org/show_bug.cgi?id=573760 Looking at the init script as of openrc-0.20.5: ~line32: # Bug 381783 local rc_svcdir=$(echo $RC_SVCDIR | sed 's:/lib\(32\|64\)\?/:/lib(32|64)?/:g') This looks relatively useless with everything migrated to /run and can most likely be removed ~line35: local m="/dev|/dev/.*|/proc|/proc.*|/sys|/sys/.*|/run|${rc_svcdir}" x= fs= Since this is a regexp it can be cut down to something more simple - why /dev and /dev/* when the second one is already excluded by the first one. Also rc_svcdir is most likely a subdir of /run ...