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
signature.asc
Description: Digital signature
