Date: Fri, 26 Jul 2024 23:17:47 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 280383] Removing the last link to an open file prevents remounting read-only--suggest document and/or code change Message-ID: <bug-280383-227-NDoUNn1lFh@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-280383-227@https.bugs.freebsd.org/bugzilla/> References: <bug-280383-227@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D280383 --- Comment #4 from Bill Blake <billblake2018@gmail.com> --- (In reply to Mark Johnston from comment #3) It occurred to me that any documentation change should probably have a few extra words. In the cases where I got bit, I didn't actually have a file o= pen. Instead, the "open files" were executables and shared libraries that were = in use. So maybe the change should also point out that executables and shared libraries that are in use count as open files. (This is a problem that bit me long ago, but I only recently got around to tracking it down. I run with /usr read-only and when I want to change something on /usr, I run a script that remounts it r/w, runs a command, and then remounts it r/o. The way I most recently got bit was doing a "pkg add= " of a shared library that the X server was using. The "pkg add" worked fine but the remount to r/o failed. In earlier cases, though I didn't realize it at= the time, the offender was a text editor I maintain. Since I almost always hav= e a running copy of that editor, if I upgraded the editor--again through that script--the remount r/o would fail until I completely exited all invocation= s of the editor.) --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-280383-227-NDoUNn1lFh>