| 1 |
-----BEGIN PGP SIGNED MESSAGE----- |
| 2 |
Hash: SHA256 |
| 3 |
|
| 4 |
On 04/08/15 11:29 AM, William Hubbs wrote: |
| 5 |
> All, |
| 6 |
> |
| 7 |
> it seems that we have mostly agreed that this proposal is a good |
| 8 |
> one, so I want to focus the discussion on the specific behaviour of |
| 9 |
> localmount and netmount. |
| 10 |
> |
| 11 |
> Currently, they mount all file systems in mass and exit |
| 12 |
> successfully regardless of whether the mounts are successful. I |
| 13 |
> feel this is a bug because it doesn't correctly report what |
| 14 |
> happened, so I want to change their behaviour so they can fail if |
| 15 |
> one of the dependent mounts fails. |
| 16 |
> |
| 17 |
> The other change I want to make, considering that the mount.* |
| 18 |
> scripts will actually do the work of mounting the file systems, is |
| 19 |
> to turn localmount and netmount into wrappers which will do nothing |
| 20 |
> other than pull in the appropriate mounts. The sys admin would have |
| 21 |
> to configure which mounts are local vs network using settings in |
| 22 |
> /etc/conf.d/{local,net}mount. |
| 23 |
> |
| 24 |
> What do folks think of these changes? |
| 25 |
> |
| 26 |
> If they are combined, is this significant enough change to warrant |
| 27 |
> a 1.0 version bump?It would be if I were removing local/netmount, |
| 28 |
> but I'm not sure whether it is since I'm basically just changing |
| 29 |
> the behaviour to fix a bug. |
| 30 |
> |
| 31 |
> William |
| 32 |
> |
| 33 |
> if |
| 34 |
> |
| 35 |
|
| 36 |
|
| 37 |
1 - if localmount fails, the you end up with everything that currently |
| 38 |
'need's localmount failing -- this means if you have a headless server |
| 39 |
someplace that reboots, you may not end up with an sshd to connect |
| 40 |
into it just to fix some random localmount failure that might not be |
| 41 |
needed for the core system. So, no, I would not like to see |
| 42 |
localmount failing unless all other services are adjusted to no longer |
| 43 |
need localmount to succeed.[**] |
| 44 |
|
| 45 |
Other implementation related questions: |
| 46 |
|
| 47 |
2 - dependencies in other services: right now we have things that |
| 48 |
need localmount. These will need to be mapped, iirc the prototype |
| 49 |
fork maps them to mount.usr and mount.var instead of 'localmount'. So |
| 50 |
what happens in the case that everything is on a single filesystem -- |
| 51 |
that is, there is no separate mount.usr / mount.var? Dependencies |
| 52 |
break in that case, no? Or will a parent mount point 'provide' the |
| 53 |
subdirectory tree to satisfy these mounts? Or will there be a totally |
| 54 |
different means of mapping filesystem parts a service needs with the |
| 55 |
mount points that need to be mounted first? How specific will the |
| 56 |
needs of a service need to be in terms of its mount dependencies in |
| 57 |
order to safely start, if for instance there is no more assurance that |
| 58 |
'localmount' has started or has successfully finished? |
| 59 |
|
| 60 |
3 - dynamic creation of services -- as of right now, openrc needs all |
| 61 |
services to exist as files/symlinks in /etc/init.d. Is it a good idea |
| 62 |
for a script to be regularly messing with /etc/init.d ? Or will |
| 63 |
openrc be changed to have a whole new means of registering |
| 64 |
dynamically-created services? |
| 65 |
|
| 66 |
4 - Dealing with dynamic creation of services at bootup -- openrc |
| 67 |
currently generates/refreshes the cache on shutdown or during config |
| 68 |
changes so that it doesn't have to do it on startup, thus speeding up |
| 69 |
startup. Since /etc/fstab could have changed between shutdown and |
| 70 |
startup (and likely not with a chroot involved -- say, after moving |
| 71 |
partitions around in a livecd env) then fstab won't match the services |
| 72 |
(nor the cache) anymore. At best this would likely mean cache |
| 73 |
regeneration, at worst it means the services need to be regenerated |
| 74 |
first. And then there's the issue of the strictness of the misaligned |
| 75 |
mount.* services in the depend() of other services (#1) upon first |
| 76 |
boot of the new /etc/fstab. |
| 77 |
|
| 78 |
|
| 79 |
[**] Now, if failure of localmount/netmount/other core services |
| 80 |
perhaps would trigger a fallover to some sort of 'rescue' runlevel, |
| 81 |
where a specific set of services would start anyways (sshd etc), then |
| 82 |
I would see this as much less of an issue. Of course if we had that, |
| 83 |
then we could set localmount to fail right now in the 'mount -a' |
| 84 |
version. This is a completely different topic though. |
| 85 |
|
| 86 |
-----BEGIN PGP SIGNATURE----- |
| 87 |
Version: GnuPG v2 |
| 88 |
|
| 89 |
iF4EAREIAAYFAlXA/tgACgkQAJxUfCtlWe3MvAEAkLE2L5mpiutGa2zemc9m2zYY |
| 90 |
YFXC1vWQhrE4OKK9uLgA/RLYGwsOI7MeZVKmYgm1XJicWF68mFbIK/EGRPpMwzyp |
| 91 |
=P0Yi |
| 92 |
-----END PGP SIGNATURE----- |
Archives