Two boot-time services provided by the venerable initscripts package: – fedora-loadmodules.service: this loads kernel modules based on configuration in /etc/rc.modules. Identical functionality is provided by systemd-modules-load.service. (systemd-modules-load.service reads modules-load.d directories and the kernel command line, not /etc/rc.modules). Is anybody still using /etc/rc.modules? It'd be nice to just drop support for /etc/rc.modules by not enabling fedora-loadmodules.service by default, and then drop it completely. - fedora-readonly.service: this is used to mount parts of the filesystem rw in case the system is using read-only root filesystem. To do anything this service checks if READONLY=yes is set in /etc/sysconfig/readonly-root. Is anybody using this? If yes, would it be OK if the service was not enabled by default anymore and would require an explicit 'systemctl enable fedora-readonly.service' or creating a custom preset (in addition to setting READONLY=yes) to be active? See https://bugzilla.redhat.com/show_bug.cgi?id=1493479 and https://pagure.io/fesco/issue/1779 for some more info. [ Why disable those services by default? The most obvious reason is that this is additional stuff the runs during boot, making things a tiny bit slower and the logs slightly more verbose. But this is very weak reason. More important is that the way those services are implemented is largely obsolete. fedora-loadmodules.service is completely duplicated by systemd-modules-load.service, so it'd make sense to drop the Fedora-specific service. fedora-readonly.service is based on mounting tmpfs dirs, copying files around, doing selinux fixups, manually mounting rpcfs and nfs, etc. I have never seen fedora-readonly.service actually used, but that doesn't mean much. If people are using them I'd love to hear about their use cases, and think if we can provide the same functionality using more modern mechanisms. Without breaking existing setups, I'd like to disable this by default to simplify the boot process and not encourage the use in new installations. ] Zbyszek _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
