Re: [systemd-devel] sys-module-fuse.device: Failed to enqueue SYSTEMD_WANTS= job, ignoring: Unit modprobe@fuse.service is masked
Am 08.02.21 um 23:42 schrieb Mike Gilbert: On Mon, Feb 8, 2021 at 2:31 PM Reindl Harald 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 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] sys-module-fuse.device: Failed to enqueue SYSTEMD_WANTS= job, ignoring: Unit modprobe@fuse.service is masked
Am 09.02.21 um 17:13 schrieb Mike Gilbert:
On Tue, Feb 9, 2021 at 6:17 AM Reindl Harald wrote:
Am 08.02.21 um 23:42 schrieb Mike Gilbert:
On Mon, Feb 8, 2021 at 2:31 PM Reindl Harald 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
[root@rawhide ~]# pstree
systemd─┬─agetty
├─dbus-broker-lau───dbus-broker
├─haveged
├─rsyslogd───2*[{rsyslogd}]
├─sshd───sshd───bash───pstree
├─systemd───(sd-pam)
├─systemd-journal
├─systemd-logind
├─systemd-udevd
└─vmtoolsd───2*[{vmtoolsd}]
[root@rawhide ~]# systemd-analyze
Startup finished in 942ms (kernel) + 1.519s (initrd) + 1.725s
(userspace) = 4.187s
multi-user.target reached after 1.692s in userspace
[root@rawhide ~]# systemd-analyze blame
376ms systemd-udev-trigger.service
309ms initrd-switch-root.service
234ms systemd-logind.service
181ms initrd-parse-etc.service
178ms network-up.service
151ms systemd-journald.service
120ms dracut-cmdline.service
118ms systemd-udevd.service
117ms systemd-vconsole-setup.service
107ms user@0.service
89ms rsyslog.service
66ms dbus-broker.service
57ms sys-kernel-tracing.mount
57ms dev-mqueue.mount
56ms sys-kernel-debug.mount
55ms dev-hugepages.mount
55ms tmp.mount
54ms kmod-static-nodes.service
46ms modprobe@drm.service
43ms systemd-sysctl.service
40ms var-lib-dnf.mount
39ms var-cache-yum.mount
39ms systemd-modules-load.service
36ms initrd-cleanup.service
36ms systemd-remount-fs.service
36ms systemd-tmpfiles-setup.service
34ms systemd-random-seed.service
33ms sys-kernel-config.mount
32ms systemd-tmpfiles-setup-dev.service
30ms systemd-fsck-root.service
30ms systemd-user-sessions.service
29ms var-log.mount
24ms systemd-update-utmp.service
23ms var-tmp.mount
23ms systemd-update-utmp-runlevel.service
22ms systemd-journal-flush.service
14ms user-runtime-dir@0.service
11ms initrd-udevadm-cleanup-db.service
9ms dracut-shutdown.service
8ms sysroot.mount
4ms modprobe@configfs.service
[root@rawhide ~]# systemctl -list-units
Failed to parse signal string t-units.
[root@rawhide ~]# systemctl list-units
UNIT
LOAD ACTIVE SUB DESCRIPTION
boot.automount
loaded active waiting boot.automount
efi.automount
loaded active waiting efi.automount
sys-devices-pci:00-:00:15.0-:03:00.0-net-lan.device
loaded active plugged VMXNET3 Ethernet
Controller
sys-devices-pci:00-:00:17.0-:13:00.0-host2-target2:0:0-2:0:0:0-block-sda-sda1.device
loaded active plugged VMware_Virtual_S EFI\x20system\x20partition
sys-devices-pci:00-:00:17.0-:13:00.0-host2-target2:0:0-2:0:0:0-block-sda-sda2.device
loaded active plugged VMware_Virtual_S BIOS\x20boot\x20partition
Re: [systemd-devel] sys-module-fuse.device: Failed to enqueue SYSTEMD_WANTS= job, ignoring: Unit modprobe@fuse.service is masked
Am 09.02.21 um 23:18 schrieb Mike Gilbert: On Tue, Feb 9, 2021 at 11:47 AM Reindl Harald wrote: Am 09.02.21 um 17:13 schrieb Mike Gilbert: On Tue, Feb 9, 2021 at 6:17 AM Reindl Harald wrote: Am 08.02.21 um 23:42 schrieb Mike Gilbert: On Mon, Feb 8, 2021 at 2:31 PM Reindl Harald 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 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] sys-module-fuse.device: Failed to enqueue SYSTEMD_WANTS= job, ignoring: Unit modprobe@fuse.service is masked
On Tue, Feb 9, 2021 at 7:19 PM Mike Gilbert wrote: > > On Tue, Feb 9, 2021 at 7:05 PM Reindl Harald wrote: > > > > > > > > Am 09.02.21 um 23:18 schrieb Mike Gilbert: > > > On Tue, Feb 9, 2021 at 11:47 AM Reindl Harald > > > wrote: > > >> > > >> > > >> > > >> Am 09.02.21 um 17:13 schrieb Mike Gilbert: > > >>> On Tue, Feb 9, 2021 at 6:17 AM Reindl Harald > > >>> wrote: > > > > > > > > Am 08.02.21 um 23:42 schrieb Mike Gilbert: > > > On Mon, Feb 8, 2021 at 2:31 PM Reindl Harald > > > 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
Re: [systemd-devel] sys-module-fuse.device: Failed to enqueue SYSTEMD_WANTS= job, ignoring: Unit modprobe@fuse.service is masked
On Tue, Feb 9, 2021 at 7:05 PM Reindl Harald wrote: > > > > Am 09.02.21 um 23:18 schrieb Mike Gilbert: > > On Tue, Feb 9, 2021 at 11:47 AM Reindl Harald > > wrote: > >> > >> > >> > >> Am 09.02.21 um 17:13 schrieb Mike Gilbert: > >>> On Tue, Feb 9, 2021 at 6:17 AM Reindl Harald > >>> wrote: > > > > Am 08.02.21 um 23:42 schrieb Mike Gilbert: > > On Mon, Feb 8, 2021 at 2:31 PM Reindl Harald > > 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@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] sys-module-fuse.device: Failed to enqueue SYSTEMD_WANTS= job, ignoring: Unit modprobe@fuse.service is masked
On Tue, Feb 9, 2021 at 11:47 AM Reindl Harald wrote: > > > > Am 09.02.21 um 17:13 schrieb Mike Gilbert: > > On Tue, Feb 9, 2021 at 6:17 AM Reindl Harald wrote: > >> > >> > >> > >> Am 08.02.21 um 23:42 schrieb Mike Gilbert: > >>> On Mon, Feb 8, 2021 at 2:31 PM Reindl Harald > >>> 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. 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. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] sys-module-fuse.device: Failed to enqueue SYSTEMD_WANTS= job, ignoring: Unit modprobe@fuse.service is masked
On Tue, Feb 9, 2021 at 6:17 AM Reindl Harald wrote: > > > > Am 08.02.21 um 23:42 schrieb Mike Gilbert: > > On Mon, Feb 8, 2021 at 2:31 PM Reindl Harald 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. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] sys-module-fuse.device: Failed to enqueue SYSTEMD_WANTS= job, ignoring: Unit modprobe@fuse.service is masked
Am 08.02.21 um 20:23 schrieb Mike Gilbert: On Mon, Feb 8, 2021 at 1:01 PM Reindl Harald wrote: Am 08.02.21 um 18:27 schrieb Lennart Poettering: On So, 07.02.21 22:43, Reindl Harald (h.rei...@thelounge.net) wrote: https://bugzilla.redhat.com/show_bug.cgi?id=1909805 In response to your actual issue, ignoring all the nasty wording: Masking is a last resort thing, you really want to use that only after having investigated everything. You use it here anyway to mask out a really low-level system thing, hence you might get warnings about this. You can of course mask sys-fs-fuse-connections.mount too who needs anything related to fuse at every boot? fuse is nothing in common used fuse is not used unconditional directly after boot on a server-vm with no fuse business [root@testserver:~]$ lsmod | grep fuse fuse 163840 1 my only usecase on 50 machines is every few weeks fuse.sshfs abd what makes people nasty is that for months nobody responds to systemd related issues in the Fedora bugracker if something is usiong fuse it happily loads the kernel module on-demand for years Looking into this a bit closer, it looks like systemd installs a symlink: /usr/lib/systemd/system/sysinit.target.wants/sys-fs-fuse-connections.mount -> ../sys-fs-fuse-connections.mount 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 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] sys-module-fuse.device: Failed to enqueue SYSTEMD_WANTS= job, ignoring: Unit modprobe@fuse.service is masked
On Mon, Feb 8, 2021 at 2:31 PM Reindl Harald 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. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] sys-module-fuse.device: Failed to enqueue SYSTEMD_WANTS= job, ignoring: Unit modprobe@fuse.service is masked
On Mon, Feb 8, 2021 at 1:01 PM Reindl Harald wrote:
>
>
>
> Am 08.02.21 um 18:27 schrieb Lennart Poettering:
> > On So, 07.02.21 22:43, Reindl Harald (h.rei...@thelounge.net) wrote:
> >
> >> https://bugzilla.redhat.com/show_bug.cgi?id=1909805
> >
> > In response to your actual issue, ignoring all the nasty wording:
> >
> > Masking is a last resort thing, you really want to use that only after
> > having investigated everything. You use it here anyway to mask out a
> > really low-level system thing, hence you might get warnings about
> > this.
> >
> > You can of course mask sys-fs-fuse-connections.mount too
> who needs anything related to fuse at every boot?
> fuse is nothing in common used
> fuse is not used unconditional
>
> directly after boot on a server-vm with no fuse business
>
> [root@testserver:~]$ lsmod | grep fuse
> fuse 163840 1
>
> my only usecase on 50 machines is every few weeks fuse.sshfs abd what
> makes people nasty is that for months nobody responds to systemd related
> issues in the Fedora bugracker
>
> if something is usiong fuse it happily loads the kernel module on-demand
> for years
Looking into this a bit closer, it looks like systemd installs a symlink:
/usr/lib/systemd/system/sysinit.target.wants/sys-fs-fuse-connections.mount
-> ../sys-fs-fuse-connections.mount
I think removing this symlink would prevent /sys/fs/fuse/connections
from being mounted and the fuse module from being loaded
unconditionally on boot.
As well, udev installs a couple of relevant rules (50-default.rules,
99-systemd.rules):
KERNEL=="fuse", MODE="0666", OPTIONS+="static_node=fuse"
# Asynchronously mount file systems implemented by these modules as
soon as they are loaded.
SUBSYSTEM=="module", KERNEL=="fuse", TAG+="systemd",
ENV{SYSTEMD_WANTS}+="sys-fs-fuse-connections.mount"
I think these rules should take care of providing a static /dev/fuse
node to allow module auto-loading, and should cause
/sys/fs/fuse/connections to be mounted on-demand.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] sys-module-fuse.device: Failed to enqueue SYSTEMD_WANTS= job, ignoring: Unit modprobe@fuse.service is masked
Am 08.02.21 um 18:27 schrieb Lennart Poettering: Masking is a last resort thing, you really want to use that only after having investigated everything. You use it here anyway to mask out a really low-level system thing, hence you might get warnings about this. You can of course mask sys-fs-fuse-connections.mount too no, you can't at least on F33 "systemctl mask sys-fs-fuse-connections.mount" only works on F32 at the moment, on F33 "sys-module-fuse.device" is masked but at the same moment "active (plugged)" and cries for "sys-fs-fuse-connections.mount" fuse kernel module is loaded on a bare install after reboot - please get your facts straight, i already tried to mask them last year *before* writing the ignored bug report at the fedora bugzilla [root@rawhide ~]# system-errors.sh Feb 8 19:17:01 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 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:17:00 CET; 5min ago Device: /sys/module/fuse Feb 08 19:17:01 rawhide.vmware.local systemd[1]: sys-module-fuse.device: Failed to enqueue SYSTEMD_WANTS= job, ignoring: Unit sys-fs-fuse-connections.mount is masked. ● sys-fs-fuse-connections.mount Loaded: masked (Reason: Unit sys-fs-fuse-connections.mount is masked.) Active: inactive (dead) [root@rawhide ~]# ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] sys-module-fuse.device: Failed to enqueue SYSTEMD_WANTS= job, ignoring: Unit modprobe@fuse.service is masked
Am 08.02.21 um 18:27 schrieb Lennart Poettering: On So, 07.02.21 22:43, Reindl Harald (h.rei...@thelounge.net) wrote: https://bugzilla.redhat.com/show_bug.cgi?id=1909805 In response to your actual issue, ignoring all the nasty wording: Masking is a last resort thing, you really want to use that only after having investigated everything. You use it here anyway to mask out a really low-level system thing, hence you might get warnings about this. You can of course mask sys-fs-fuse-connections.mount too who needs anything related to fuse at every boot? fuse is nothing in common used fuse is not used unconditional directly after boot on a server-vm with no fuse business [root@testserver:~]$ lsmod | grep fuse fuse 163840 1 my only usecase on 50 machines is every few weeks fuse.sshfs abd what makes people nasty is that for months nobody responds to systemd related issues in the Fedora bugracker if something is usiong fuse it happily loads the kernel module on-demand for years ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] sys-module-fuse.device: Failed to enqueue SYSTEMD_WANTS= job, ignoring: Unit modprobe@fuse.service is masked
On So, 07.02.21 22:43, Reindl Harald (h.rei...@thelounge.net) wrote: > https://bugzilla.redhat.com/show_bug.cgi?id=1909805 > > what is this new nonsense given that only one out of 50 installs here have a > business for fuse at all and there is no reason to load/touch any fuse > related stuff at boot No need for that tone. "nonsense", "what the hell", "annoying shit". come on! Reindl, this is you last chance. If you can't control yourself I'll block you from the mailing list altogether. You have been moderated so very often, and I really don't care for doing that anymore. You are by far the person that has been on and off the moderation list the most. If I read one more mail like this from you you are off the list. And no, don't come back and argue about this. I had enough. People have previusly asked me privately to ban you already. We gave you so much leeway anyway, but enough is enough. One more post like this and it's over. In response to your actual issue, ignoring all the nasty wording: Masking is a last resort thing, you really want to use that only after having investigated everything. You use it here anyway to mask out a really low-level system thing, hence you might get warnings about this. You can of course mask sys-fs-fuse-connections.mount too. Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
