init.sh mounts tmpfs on /run already. /etc/init.d/bootmisc checks / read-write permissions and assumes that /run has the same permissions as /. When the / is read-only, but not /run, this causes the clean_run() function to error out prematurely. Reproducible: Always
The purpose of the clean_run function is to make sure no files are in the /run mount point. This is the underlying directory for the /run tmpfs; not the tmpfs itself. The clean_run function exits if / is not writable, because I can't think of a situation where / would not be writable and /run (the directory, not the tmpfs) would be writable. What is the situation you think I am missing?
Hello William, Thanks for taking a look at this. (In reply to William Hubbs from comment #1) > The purpose of the clean_run function is to make sure no files are in the > /run mount point. This is the underlying directory for the /run tmpfs; not > the tmpfs itself. > > The clean_run function exits if / is not writable, because I can't think of > a situation where / would not be writable and /run (the directory, not the > tmpfs) would be writable. > > What is the situation you think I am missing? Below is the corresponding code in //lib64/rc/sh/init.sh. It is mounting /run already. When the clean_run function starts, the / and /run are different. Does that make sense or am I missing something? Thanks ------------------------------------------------------------ # /run is a new directory for storing volatile runtime data. # Read more about /run at https://lwn.net/Articles/436012 sys="$(openrc --sys)" if [ ! -d /run ]; then if [ "$sys" = VSERVER ]; then if [ -e /run ]; then rm -rf /run fi mkdir /run else eerror "The /run directory does not exist. Unable to continue." return 1 fi fi if [ "$sys" = VSERVER ]; then rm -rf /run/* elif ! mountinfo -q /run; then ebegin "Mounting /run" rc=0 if ! fstabinfo --mount /run; then mount -t tmpfs -o mode=0755,nodev,size=10% tmpfs /run rc=$? fi if [ $rc != 0 ]; then eerror "Unable to mount tmpfs on /run." eerror "Can't continue." exit 1 fi fi checkpath -d $RC_SVCDIR checkpath -d -m 0775 -o root:uucp /run/lock
(In reply to Joe M from comment #2) > Hello William, > > Thanks for taking a look at this. > > (In reply to William Hubbs from comment #1) > > The purpose of the clean_run function is to make sure no files are in the > > /run mount point. This is the underlying directory for the /run tmpfs; not > > the tmpfs itself. > > > > The clean_run function exits if / is not writable, because I can't think of > > a situation where / would not be writable and /run (the directory, not the > > tmpfs) would be writable. > > > > What is the situation you think I am missing? > > Below is the corresponding code in //lib64/rc/sh/init.sh. It is mounting > /run already. When the clean_run function starts, the / and /run are > different. Does that make sense or am I missing something? The code in clean_run is not trying to clean out the tmpfs that is mounted by init.sh. It is trying to clean out the underlying /run directory which will have different content, and most of the time should have none. William
> The code in clean_run is not trying to clean out the tmpfs that is mounted > by init.sh. It is trying to clean out the underlying /run directory which > will have different content, and most of the time should have none. Makes sense, Thanks. This errors out when I have a readonly root. The error is harmless, hence, want to check if it needs to be an error.
I agree that this should not be an error. When / is read-only, this message is guaranteed to be shown (even if there is nothing to clean), but there is no real problem. If there is anything in the hidden /run directory, it will make no difference. If you really want to display the message, it should at least be changed to ewarn.
Several messages in the clean_run function have beeen converted to warnings since this function does not affect operation of the system. This has been done in commit bf0c0dd. Thanks, William
