[systemd-devel] sys-module-fuse.device: Failed to enqueue SYSTEMD_WANTS= job, ignoring: Unit modprobe at fuse.service is masked

[Mike Gilbert]

On Tue, Feb 9, 2021 at 11:47 AM Reindl Harald <h.reindl at thelounge.net> wrote:
>
>
>
> Am 09.02.21 um 17:13 schrieb Mike Gilbert:
> > On Tue, Feb 9, 2021 at 6:17 AM Reindl Harald <h.reindl at thelounge.net> wrote:
> >>
> >>
> >>
> >> Am 08.02.21 um 23:42 schrieb Mike Gilbert:
> >>> On Mon, Feb 8, 2021 at 2:31 PM Reindl Harald <h.reindl at thelounge.net> wrote:
> >>>>> I think removing this symlink would prevent /sys/fs/fuse/connections
> >>>>> from being mounted and the fuse module from being loaded
> >>>>> unconditionally on boot
> >>>>
> >>>> no
> >>>>
> >>>> https://bugzilla.redhat.com/show_bug.cgi?id=1909805#c6
> >>>
> >>> It almost works for me on Gentoo Linux.
> >>> To test, I first had to reconfigure my kernel to build FUSE as a
> >>> module (I normally have it built-in).
> >>> I then removed the sys-fs-fuse-connections.mount symlink from
> >>> sysinit.target.wants.
> >>> After rebooting with the new kernel, the FUSE module is not loaded and
> >>> /sys/fs/fuse/connections is not mounted.
> >>>
> >>> Unfortunately, mounting FUSE-based file systems does not work until I
> >>> manually run "modprobe fuse".
> >>> It seems that my kernel does not auto-load the module, despite the
> >>> static /dev/fuse node. The kernel is probably missing a call to
> >>> __request_module().
> >>>
> >>> Given that the kernel doesn't auto-load the module on demand, leaving
> >>> the sysinit.target.wants symlink in place seems like the safe thing to
> >>> do.
> >>
> >> but for sure not on a stripped down machine running a iptables-nft
> >> ruleset, a socket-activated sshd and nohting else
> >>
> >> if it's me for server setups the "fuse" kernel-module could be in
> >> "kernel-modules" which is not installed and needed for virtualized guests
> >>
> >> the point is that all this setups where happy without fuse loaded from
> >> 2008 to 2021 and you can't even avoid it with F33 at all, no matter what
> >> you delete or mask
> >>
> >> a active masked unit - seriously? :-)
> >>
> >> [root at rawhide ~]# systemctl status sys-module-fuse.device
> >> sys-fs-fuse-connections.mount
> >> ● sys-module-fuse.device - /sys/module/fuse
> >>        Loaded: masked (Reason: Unit sys-module-fuse.device is masked.)
> >>        Active: active (plugged) since Mon 2021-02-08 19:33:18 CET; 1min
> >> 42s ago
> >>        Device: /sys/module/fuse
> >
> > I think something else on your system is loading the fuse kernel
> > module, which activates sys-module-fuse.device, and tries to start
> > sys-fs-fuse-connections.mount. It appears systemd doesn't really
> > support masking device units, which are generated by udev events.
> >
> > You should probably try to track down exactly what else is loading the
> > fuse module, and disable that.
>
> this is a bare setup with *nothing* enabled at all

Off the top of my head, maybe fuse is getting loaded by an entry in
modules-load.d.

Also, vmware tools might utilize FUSE in some way.

If you're unable to figure out what is loading it, you might replace
/sbin/modprobe with a wrapper script to log all processes that call
it.