[gentoo-dev] Re: rfc: openrc mount service prototype

[Duncan]

Brian Dolbec posted on Mon, 03 Aug 2015 00:59:07 -0700 as excerpted:

> On Mon, 3 Aug 2015 00:47:24 -0700 Brian Dolbec <dolsen@g.o>
> wrote:
>>
>> On Mon, 3 Aug 2015 00:22:42 -0700 "Daniel Campbell (zlg)"
>> <zlg@g.o> wrote:
>>
>> > I'm having a hard time understanding why we need daemons to handle
>> > our filesystems. Can you give me a use case that /etc/fstab is
>> > insufficient for solving?

>> It is about defining proper dependencies and not blindly returning a
>> success result when there were actual failures to start some files
>> systems.
>> So in some ways it is a bugfix.  But it is actually a re-design which
>> will overcome shortcomings/limitations in the fstab, netmount,
>> localmount designs.
>
> For the average joe user that only has a few fstab entries,  /boot,
> /root,/home. swap...
>
> It won't mean much if anything other than an un-needed change.  Since it
> works for them.
>
> But for a systems administrator configuring servers with virtual
> machines, services depending on certain or multiple filesystems being
> up, etc... It can mean a BIG difference.  It is the more complicated
> systems that are hitting the limitations of the current fstab system.
> not the simple user with a standard/basic handbook install.

[TL;DR folks, skip to last paragraph.]

Any time there's nested mounts, say /var/log on /var, on /, or /usr/local 
on /usr, on /, there's dependency issues that the current openrc 
localmount and netmount services don't deal with explicitly.  If it 
happens to work, great, but sometimes it doesn't.

Back on openrc, I used to have this problem with some custom bindmounts I 
did for a chrooted service.  They were nested mounts, bind-mounting 
something that itself was on a separate filesystem, and openrc's 
localmount just doesn't deal well with that sort of thing, so I had to 
roll my own latelocalmount service, with the mounts marked noauto so 
localmount didn't try to mount them before their source filesystems were 
mounted, then explicitly mounted by name, in the latemount service.  If 
I'd have had multiple layers of nesting, I would have needed multiple 
layers of mounting services.

That gets to be a nightmare pretty quickly, all because openrc's existing 
mount services handle things en-mass, there's no way to explicitly 
specify dependencies of one mount on others, either at the mount level, 
or with the service, since individual mount services don't exist, only 
the en-mass localmount and netmount services.  It was and remains a mess.

To my very pleasant surprise, when I switched to systemd, most of those 
mounts "just worked", because systemd uses an internally multiplexed 
individual mount approach instead of the en-mass approach openrc 
currently uses, and systemd automatically calculates dependencies.  The 
one that systemd did NOT handle correctly by default was because it was a 
symlink, and apparently systemd's automated dependency handling doesn't 
deal with symlinks.  (Not that I can blame it, symlinks can go circular 
or dangling, and the calculations get complex pretty quickly.  But it 
handles the non-symlink cases _surprisingly_ well!)  And that one had a 
simple fix, adding a single line to the service unit depending on that 
mount (it was an early-boot service so had the default deps of all mounts 
done turned off, but still would have detected the need for the mount 
based on path, if it was a straight path, not symlinked), making explicit 
the mount dependency so systemd could follow the dependency logic and 
would ensure that mount was completed before trying to start the service 
that depended on it.


Long story short, systemd has upped the expectancy by handling these 
things automatically in most cases and making it very simple to add 
explicit mount deps where systemd's automatic handling fails, so other 
init systems must either match that expectancy now too, or fall further 
behind.  The expectations have changed, and forcing the admin to jump 
thru a series of complex hack hoops to get nested mounts, etc, working, 
simply doesn't cut it any more.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman