Re: sys-module-fuse.device: Failed to enqueue SYSTEMD_WANTS= job, ignoring: Unit modprobe@fuse.service is masked

[Mike Gilbert <floppym@xxxxxxxxxx>]

On Tue, Feb 9, 2021 at 7:05 PM Reindl Harald <h.reindl@xxxxxxxxxxxxx> wrote:
>
>
>
> Am 09.02.21 um 23:18 schrieb Mike Gilbert:
> > On Tue, Feb 9, 2021 at 11:47 AM Reindl Harald <h.reindl@xxxxxxxxxxxxx> wrote:
> >>
> >>
> >>
> >> Am 09.02.21 um 17:13 schrieb Mike Gilbert:
> >>> On Tue, Feb 9, 2021 at 6:17 AM Reindl Harald <h.reindl@xxxxxxxxxxxxx> wrote:
> >>>>
> >>>>
> >>>>
> >>>> Am 08.02.21 um 23:42 schrieb Mike Gilbert:
> >>>>> On Mon, Feb 8, 2021 at 2:31 PM Reindl Harald <h.reindl@xxxxxxxxxxxxx> 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@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.
>
> no
>
> [root@rawhide ~]# ls /etc/modules-load.d/
> total 0
>
> > Also, vmware tools might utilize FUSE in some way.
>
> no
>
> [root@rawhide ~]# system-errors.sh
> Feb 10 00:59:22 rawhide systemd[1]: sys-module-fuse.device: Failed to
> enqueue SYSTEMD_WANTS= job, ignoring: Unit sys-fs-fuse-connections.mount
> is masked.
> [root@rawhide ~]# systemctl status vmtoolsd.service
> ● vmtoolsd.service - VMware Tools
>       Loaded: loaded (/etc/systemd/system/vmtoolsd.service; disabled;
> vendor preset: enabled)
>       Active: inactive (dead)
>
> even that file from the vmtools package was deleted long before my
> initial post of this thread
>
> [root@rawhide ~]# cat /usr/lib/systemd/system/run-vmblock\x2dfuse.mount
> cat: /usr/lib/systemd/system/run-vmblockx2dfuse.mount: No such file or
> directory
>
> > 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
> there is nothing left but systemd which also don't go the normal way
> otherwise this below would prevent loading the kernel module
>
> modprobe won't load it in that case
>
> [root@rawhide ~]# cat /etc/modprobe.d/blacklist-lounge-vm.conf | grep fuse
> blacklist fuse
> install fuse /usr/bin/true
>

The blacklist is only applied if you call "modprobe -b". Possibly
something else is calling modprobe without the -b option.
_______________________________________________
systemd-devel mailing list
systemd-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/systemd-devel