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

Reindl Harald h.reindl at thelounge.net
Wed Feb 10 00:05:33 UTC 2021



Am 09.02.21 um 23:18 schrieb 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.

no

[root at rawhide ~]# ls /etc/modules-load.d/
total 0

> Also, vmware tools might utilize FUSE in some way.

no

[root at 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 at 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 at 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 at rawhide ~]# cat /etc/modprobe.d/blacklist-lounge-vm.conf | grep fuse
blacklist fuse
install fuse /usr/bin/true



More information about the systemd-devel mailing list