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:19 PM Mike Gilbert <floppym@xxxxxxxxxx> wrote:
>
> 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.

Also, it might be loaded by something in the initramfs (assuming you have one).

Anyway, I think I will stop spoon feeding you ideas at this point. I'm
sure you are capable of poking around files on your own system.
_______________________________________________
systemd-devel mailing list
systemd-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/systemd-devel