Re: [gentoo-dev] rfc: improve file system mounting and unmounting in OpenRC

[William Hubbs]

On Tue, Aug 04, 2015 at 02:05:12PM -0400, Ian Stakenvicius wrote:
> 1 - if localmount fails, the you end up with everything that currently
> 'need's localmount failing -- this means if you have a headless server
> someplace that reboots, you may not end up with an sshd to connect
> into it just to fix some random localmount failure that might not be
> needed for the core system.  So, no, I would not like to see
> localmount failing unless all other services are adjusted to no longer
> need localmount to succeed.[**]

This sounds like more an issue with which file systems are critical for
mounting, and a good argument for getting rid of localmount.

If we don't care whether localmount succeeds or not, the need dependency
is the wrong one to use.

Maybe we do think certain file systems must be mounted to boot
successfully, and if we do, those should have need dependencies and
cause failure if they are unable to be mounted, but the others should
not.

This is a good reason in itself to move away from localmount and
netmount.


>
> Other implementation related questions:
>
> 2 - dependencies in other services:  right now we have things that
> need localmount.  These will need to be mapped, iirc the prototype
> fork maps them to mount.usr and mount.var instead of 'localmount'.  So
> what happens in the case that everything is on a single filesystem --
> that is, there is no separate mount.usr / mount.var?  Dependencies
> break in that case, no?  Or will a parent mount point 'provide' the
> subdirectory tree to satisfy these mounts?  Or will there be a totally
> different means of mapping filesystem parts a service needs with the
> mount points that need to be mounted first?  How specific will the
> needs of a service need to be in terms of its mount dependencies in
> order to safely start, if for instance there is no more assurance that
> 'localmount' has started or has successfully finished?
 
My thought on this is that if you have a mount.foobar service and its
mountpoint is not listed in fstab, the service would output a message
and return success. This should cover the case of a file system being
needed but not being a real file system.

From the user's side, you could, if everything was on a single file
system, just use rc_need in /etc/conf.d/* to remove mount.usr and
mount.var from everything.

> 3 - dynamic creation of services -- as of right now, openrc needs all
> services to exist as files/symlinks in /etc/init.d.  Is it a good idea
> for a script to be regularly messing with /etc/init.d ?  Or will
> openrc be changed to have a whole new means of registering
> dynamically-created services?

To be honest, I am not really a fan of dynamically created services; I
would rather not go there. We don't do that for net.*, so I don't think
we should for mount.*.

> 4 - Dealing with dynamic creation of services at bootup -- openrc
> currently generates/refreshes the cache on shutdown or during config
> changes so that it doesn't have to do it on startup, thus speeding up
> startup.  Since /etc/fstab could have changed between shutdown and
> startup (and likely not with a chroot involved -- say, after moving
> partitions around in a livecd env) then fstab won't match the services
> (nor the cache) anymore.  At best this would likely mean cache
> regeneration, at worst it means the services need to be regenerated
> first.  And then there's the issue of the strictness of the misaligned
> mount.* services in the depend() of other services (#1) upon first
> boot of the new /etc/fstab.

I'm not exactly sure what the answer would be here, except that you
would have to keep the symlinks in sync with fstab.

I'm thinking that there will be a couple of defaults (mount.usr and
mount.var) that will take care of most situations.

Like I said though, any ideas would be good.

William