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

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 04/08/15 04:40 PM, William Hubbs wrote:
> 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.
>
>

You may have misunderstood what I meant here.

Right now, most if not all services expect localmount to have
completed successfully before they will start, right?  That's the
whole reason why localmount as it is now doesn't fail.  What you are
suggesting here is to make it fail.  It doesn't matter whether we use
the per-mount service underneath localmount or keep it as a "mount -a"
wrapper, in both cases when "localmount" fails we get failures and
services wont start.

So what you are suggesting here now is that you want to (A)
potentially break mounting with the need to externally manage mounts
via services in openrc instead of just using /etc/fstab, and (B) also
break services if something doesn't start, which is one of the reasons
why you wanted to go through with this per-mount service in the first
place.  My point is that no, we should keep localmount as succeeding
even if one of the dependent services fails to mount, *just like it
does right now*, *for the same reasons* as it succeeds on failure
right now.



>>
>> 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.
>

But what services will shipped init scripts be specifying in
depend()??  mount.usr and mount.var are (A) only true in certain cases
(things can just as easily be /var/lib , /var/log , /usr/share , etc),
and (B) outright wrong if someone just has everything on one root
filesystem.  Are you suggesting now that not only will everyone have
to set up their services / sync them with /etc/fstab but they'll also
have to set all mount-point dependencies in their services too?



>> 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.
>


And this is why I am -not- a fan of this being the default
implementation of mounting in openrc (and -definitely- not the only
one).  A single service for local mounting, whether it be 'mount -a'
or internally mounting each filesystem individually, allows
practically all mounting to be completed in a service-agnostic manner.
 To properly set up mounting otherwise simply requires too much work,
way more than should be necessary.  Its pretty much the same as
dropping 'net' from depend in favour of forcing end-users to set up
rc_need='net.[iface]' on their own, only an order of magnitude worse.

Realistically, I think it would be better for openrc to handle this
new mounting separately from /etc/fstab if the end-user is expected to
manage it themselves as is described above, at least then there won't
be any confusion about this new per-service mounting being an openrc
thing and not something meant to work in any sort of linux-generic
manner like what one would expect from using /etc/fstab.

Otherwise, IMO, openrc needs to provide mounting from /etc/fstab and
/etc/fstab alone, not requiring the end-user to sync things by hand or
otherwise.  And to do that cleanly IMO requires a rather large amount
of changes to some rather core portions of openrc in order to
implement dynamic services and/or non-service depend(s), and make
cache generation and cache usage work alongside them.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iF4EAREIAAYFAlXBK/8ACgkQAJxUfCtlWe3ZOwD+MmQUdhsGEnPtBgmBh7VEeOnc
YHA/8d+fCgqQM5aveZEA/AgJ7MjIcgs3Dctd6OQJZkeW9hoibBK32bfuM2GA3C6b
=qZAT
-----END PGP SIGNATURE-----