On Mo, 27.07.20 20:27, Tomasz Kłoczko (kloczko.tomasz(a)gmail.com) wrote:
On Mon, 27 Jul 2020 at 20:05, Zbigniew Jędrzejewski-Szmek
> > So (a bit off-topic) what was wrong with autofs as a separate small
> > started only when it was necessary? Do you remember that?
> Having automount support directly in pid1 allows automounts to be part
> of the unit graph — with dependencies and triggering and failure actions.
> The code to talk to the kernel interface is rather simple. The part
> to tie into the rest of the unit framework is bigger. Having a separate
> daemon would only make that bigger part even more complicated.
Still it does not explain why automonting cannot be just a regular unit
with a separated process.
That way it still can be part of the "the unit graph", and both systemd
units and SMF services are using dependencies.
As communication with kennel space is done over /de/autofs and just checked
and autofs and systemd are using that interface almost the same way.
If you have a service you need to stop when unmounting a .mount unit
that is wrapped by an autofs, then you need to do that in the right
order, which is easy if .automount and .mount are known to systemd and
things can just be ordered using the usual dependency tree. But if you
do all that outside of systemd then you either have to communicate a
lot between that process and PID 1 or the service needs to be a child
process of that process, and thus live outside of systemd service
management, i.e. have no sandboxing, no resource mgmt, not dep tree
integration and so on. The communication between that outside process
and PID 1 would be at least as complex (probably many times so) as the
syscall/ioctl iface between PID 1 in the kernel if we just do it
ourselves. I mean, that's the thing here: IPC comes at a cost, and the
IPC that the kernel API is is really nice to use, it's just function
calls exported by glibc.
Splitting out stuff into process makes a lot of sense, if they either
are complex or dangerous. But the autofs ioctl calling is
neither. It's simple and not anymore dangerous than calling mount() itself...
At the moment it seems that the autofs bit is used only to mout per
user tmpfs which looks like it could be mounted/umounted using the user
systemd unit WITHOUT automounter. Am I right? If yes, using the
We do not use the automount logic for that. We do use it for mounting
the ESP/boot loader partition (unless OS overrides that and turns this
out, which Fedora/Anaconda unfortunately — needlessly — do), for
binfmt_misc and removable USB device handling.
is kind of overkill because all that could be done without autofs.
have in kernel autofs and in userspace communication over /dev/autofs thi
could be done with a top 0.5KB systemd unit yext file which will execute
mount/umount commands with some exact params.
I don't think it's worth pulling in yet another package just for
calling a few ioctls, sorry.
Lennart Poettering, Berlin