-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On 04/08/15 11:29 AM, William Hubbs wrote:
> All,
>
> it seems that we have mostly agreed that this proposal is a good
> one, so I want to focus the discussion on the specific behaviour of
> localmount and netmount.
>
> Currently, they mount all file systems in mass and exit
> successfully regardless of whether the mounts are successful. I
> feel this is a bug because it doesn't correctly report what
> happened, so I want to change their behaviour so they can fail if
> one of the dependent mounts fails.
>
> The other change I want to make, considering that the mount.*
> scripts will actually do the work of mounting the file systems, is
> to turn localmount and netmount into wrappers which will do nothing
> other than pull in the appropriate mounts. The sys admin would have
> to configure which mounts are local vs network using settings in
> /etc/conf.d/{local,net}mount.
>
> What do folks think of these changes?
>
> If they are combined, is this significant enough change to warrant
> a 1.0 version bump?It would be if I were removing local/netmount,
> but I'm not sure whether it is since I'm basically just changing
> the behaviour to fix a bug.
>
> William
>
> if
>
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.[**]
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?
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?
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.
[**] Now, if failure of localmount/netmount/other core services
perhaps would trigger a fallover to some sort of 'rescue' runlevel,
where a specific set of services would start anyways (sshd etc), then
I would see this as much less of an issue. Of course if we had that,
then we could set localmount to fail right now in the 'mount -a'
version. This is a completely different topic though.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iF4EAREIAAYFAlXA/tgACgkQAJxUfCtlWe3MvAEAkLE2L5mpiutGa2zemc9m2zYY
YFXC1vWQhrE4OKK9uLgA/RLYGwsOI7MeZVKmYgm1XJicWF68mFbIK/EGRPpMwzyp
=P0Yi
-----END PGP SIGNATURE-----
