On Mo, 27.07.20 20:27, Tomasz Kłoczko (kloczko.tomasz@xxxxxxxxx) wrote: > On Mon, 27 Jul 2020 at 20:05, Zbigniew Jędrzejewski-Szmek <zbyszek@xxxxxxxxx> > wrote: > [..] > > > > So (a bit off-topic) what was wrong with autofs as a separate small > > process > > > 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 logged > user tmpfs which looks like it could be mounted/umounted using the user > systemd unit WITHOUT automounter. Am I right? If yes, using the > automonter 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. Instead > 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 -- Lennart Poettering, Berlin _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
