/usr/lib/modules-load.d systemd affecting openrc

[josephg]

Gentoo has never automagically enabled anything just because it is installed.
The closest parallel is with daemons; just because they're installed, does not mean the admin is ready to deal with them being started automatically, nor even wants that.

in this case, a daemon called modules-load starts automagically to load stuff from systemd locations (ref op). i can't disable that service as it's not enabled, nor listed on any runlevels.
it was a surprise to me, as it's not documented anywhere.

If a bindist wants to, that's their choice, and sod-all to do with what is best for Gentoo users.
And yes, what you're discussing here is again from the point of view of an upstream developer; and sorry, no you don't always know best: that's why we have distros.

Gentoo is not an idiot-box distribution; if an admin wants to set up autoload for their users, they can do it themselves.
The alternative breaks the principle of least-surprise, for no good reason, especially so given the context.

and that's why we have docs. those who come to gentoo do so for very specific reasons, least of all plug-and-pray!

[steveL]

Those who come to gentoo do so for very specific reasons, least of all plug-and-pray!

Heh; ++

[josephg]

i just had a brainwave, and decided to test it.. all working fine and a non-destructive fix.

simple solution: disable this daemon modules-load

Code: Select all

# chmod -x /etc/init.d/modules-load

[i4dnf]

I think that fix will be "unfixed" the next time you update openrc, especially if it contains an updated /etc/init.d/modules-load file. (I don't think the tools dealing with CONFIG_PROTECT mechanism get "activated" on file permissions only.)
Modifying the /etc/init.d/modules file and commenting out the modules-load dependecy prevents modules-load from autoloading and also, in case an update openrc contains a modified file you'll be able to inspect the changes via dispatch-conf, or whatever your prefered method.

[josephg]

I think that fix will be "unfixed" the next time you update openrc, especially if it contains an updated /etc/init.d/modules-load file. (I don't think the tools dealing with CONFIG_PROTECT mechanism get "activated" on file permissions only.)

hmm.. and you are right! i tested this, and indeed the next emerge resets the permission bits, no relevant messages.

Modifying the /etc/init.d/modules file and commenting out the modules-load dependecy prevents modules-load from autoloading and also, in case an update openrc contains a modified file you'll be able to inspect the changes via dispatch-conf, or whatever your prefered method.

i'm loathe to edit /etc/init.d, and imho preferable to edit /etc/conf.d
i know i can add depends in /etc/conf.d, but can i disable/negate depends want in /etc/conf.d/modules?

[i4dnf]

Hmm, openrc manual (man openrc-run) says the !modules-load should work.
i.e in /etc/conf.d/modules

Code: Select all

rc_want="!modules-load"

[josephg]

i couldn't find rc_want in man openrc-run, but i have tested this and it works. i think this workaround is better than the previous ones as /etc/init.d/ remains pristine.

Code: Select all

$ cat /etc/conf.d/modules
rc_want="!modules-load"

i4dnf, thank you! this is perfect fits in with the gentoo policy of modifying /etc/conf.d/ rather than /etc/init.d/
also keeps this change across emerge/updates

personally i think gentoo/openrc should remove this "want modules-load" from /etc/init.d/modules, and allow user/sysadmin to add modules-load to any runlevel (just like any other service) if this is wanted. for eg

Code: Select all

# rc-update add modules-load boot

this also means those who don't want this systemd behaviour can remove modules-load service from any runlevels.

[i4dnf]

i couldn't find rc_want in man openrc-run, but i have tested this and it works.

With the exception of /etc/rc.conf, the configuration files can also influence the dependencies of the service through variables. Simply prefix the name of the dependency with rc_.

In openrc-run speak dependencies are any of: need, use, want, after, before, provide, config, keyword

[josephg]

thanks again i4dnf

and another distro which suggests openrc has this to say about modules-load.d:

For OpenRC, the modules to be loaded at boot are specified in /etc/conf.d/modules rather than being present as individual files in /etc/modules-load.d

The required modules can be manually moved over.

[pjp]

Locking this thread for the time being.

As it is solved, I'll see about extracting the unrelated content later.

@steveL & mv: I've replied to the report post and separated it to its own thread. Please see that thread.

[split]steveL & mv

In the meantime, please stop engaging each other.

EDIT: Unlocked and split off some of the posts by steveL and mv.

[josephg]

reopened: latest version of openrc loads modules from systemd locations and does not respect rc_wants workaround which solved the OP issue.

[josephg]

digging further… previous versions of openrc had a modules-load service to replicate systemd behaviour of automagically loading modules from systemd locations. modules-load was automatically called by modules service. the workaround blocked modules-load service.

this workaround does not work anymore, because the latest openrc removed that modules-load service and subsumed it inside the modules service. so now we can't block modules-load because it doesn't exist. do we now entirely block modules service? i feel a bit wary.

[Naib]

/etc/init.d/modules

Code: Select all

find_modfiles()
{
	local dirs="/usr/lib/modules-load.d /run/modules-load.d /etc/modules-load.d"

1) Why the hell /usr/lib ... if an administrator now needs to disable something they need to edit part of a lib and NOT in etc (where such things are controlled from)

2) WHY THE HELL /run a tmpfs directory mounted at boot...

http://refspecs.linuxfoundation.org/FHS ... figuration

/etc : Host-specific system configuration
3.7.1. Purpose
The /etc hierarchy contains configuration files. A "configuration file" is a local file used to control the operation of a program; it must be static and cannot be an executable binary. [2]

/usr/lib : Libraries for programming and packages
4.6.1. Purpose
/usr/lib includes object files and libraries. [21] On some systems, it may also include internal binaries that are not intended to be executed directly by users or shell scripts. [22]

Applications may use a single subdirectory under /usr/lib. If an application uses a subdirectory, all architecture-dependent data exclusively used by the application must be placed within that subdirectory. [23]

Fair enough storing the actual modules in /usr/lib/* but the control of this should be via /etc

[Tony0945]

A program is not a library. /usr/bin is more appropriate than /usr/lib
Concur regarding /etc for configuration.

[mv]

if an administrator now needs to disable something they need to edit part of a lib and NOT in etc

No, it is always sufficient to edit in etc (see below).

storing the actual modules in /usr/lib/* but the control of this should be via /etc

That's how the mechanism is meant to be used: /usr/lib contains only the defaults. You can override these with /etc: If a file with the same name exists in /etc that one will be used, and the corresponding file from /usr/lib will be ignored in that case. In particular, to "remove" a file from /usr/lib you can just create an empty file (or a symlink to /dev/null) in /etc with the corresponding name.
The advantage of this is that the defaults as well as your local changes are both always accessible without using any backup or special features of a package manager. Another advantage is that in /etc really only local changes are stored which simplifies things if you want to see what you modified locally (e.g. to initialize another machine, or for backup purposes). Yet another advantage is that a package update can simply update the defaults. A disadvantage is that it is less obvious when this happens.