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

## josephg

i have virtualbox installed, used rarely. default virtualbox install has all vbox modules autoload at boot. on one of my usual iterations of cutting & pruning my gentoo, i decided that i will load virtualbox modules manually only when i want to run virtualbox.

digging a bit deeper, i find gentoo is automagically loading modules from systemd location /usr/lib/modules-load.d/, even though systemd is masked.

 *http://manpages.ubuntu.com/manpages/zesty/man5/modules-load.d.5.html wrote:*   

> Provided by: systemd_232-7_amd64 bug

 

have i misconfigured something.. why is my gentoo running systemd bits n bobs? i now have to use systemd workarounds to stop this.

resolved: either of two workarounds (till openrc decides to fix/kill itself)

(a) systemd method

(b) gentoo/openrc method

update: latest version of openrc loads modules from systemd locations. now the systemd method (a) works, openrc method (b) does not work. i was using (b), and am now using (a). 

moral of the story: when openrc breaks while trying to emulate systemd, look for systemd solutions as workarounds.

----------

## NeddySeagoon

josephg,

Things that provide systemd unit files will still install them but they should not be used.

I have systemd in package.mask and USE=-systemd

I also have

```
INSTALL_MASK="${INSTALL_MASK} /usr/lib/systemd *.la"
```

 in make.conf so that anything that goes in /usr/lib/systemd is thrown away.

The *.la is irrelevant now. Gentoo used to install Linker Archve (*.la) files which play havoc with cross compiling.

That's no longer the case, so I can drop that. 

I'm told its a horrible hack and that I'll regret it if I ever want to move to systemd.

Its more likely I'll move to BSD than systemd, so right now, it works for me.

----------

## Tony0945

 *NeddySeagoon wrote:*   

> Its more likely I'll move to BSD than systemd, so right now, it works for me.

  Amen!

----------

## josephg

 *Tony0945 wrote:*   

>  *NeddySeagoon wrote:*   Its more likely I'll move to BSD than systemd, so right now, it works for me.  Amen!

 

me too!

i've been using openbsd off and on for the past few years, less so since i moved to gentoo. i'm looking at freebsd, which allows you to stay on an older release and continue getting security updates, without upgrading everything all the time or be damned!

 *NeddySeagoon wrote:*   

> Things that provide systemd unit files will still install them but they should not be used.

 

well, i want to agree but my gentoo without systemd autoloads those four modules, and i have to use systemd workarounds to stop them.

to stop /usr/lib/modules-load.d/virtualbox.conf from autoloading at boot, i created that directory in /etc, and did "ln -s /dev/null /etc/modules-load.d/virtualbox.conf"  :Sad:  duh!

i don't even know how this automagic happens. there's a service modules-load, but it's not enabled nor listed on any openrc runlevels.

----------

## Josef.95

Oh no, the systemd haters...   :Crying or Very sad: 

Hm no, systemd and OpenRC loads module automatically from /etc/modules-load.d/*

or OpenRC from /etc/conf.d/modules to, if you have it configured.

Without configuration it would not load modules automatically.

Remove the modules from /etc/modules-load.d/* and /etc/conf.d/modules should help.

----------

## josephg

 *Josef.95 wrote:*   

> Oh no, the systemd haters...   

 

 :Crying or Very sad:  shall we call you openrc haters? i don't hate you or label you just because you want systemd! just don't impose it on us..   :Rolling Eyes: 

yes i can remove those conf files from /usr/lib/modules-load.d/, but emerge will create them again.Last edited by josephg on Sun Jul 30, 2017 2:49 am; edited 4 times in total

----------

## Josef.95

 *josephg wrote:*   

> [...]
> 
> yes i can remove those conf files from /usr/lib/modules-load.d/, but emerge will create them again.

 

No, I meant /etc/ not /usr/

From /usr/lib/modules-load.d/virtualbox.conf it would not load automatically (on Gentoo).

----------

## josephg

 *Josef.95 wrote:*   

> From /usr/lib/modules-load.d/virtualbox.conf it would not load automatically (on Gentoo).

 

/usr/lib/modules-load.d/virtualbox.conf does load automatically on this gentoo. i manually created /etc/modules-load.d/* to stop auto load.

i don't have any vbox modules listed anywhere in /etc..

----------

## NeddySeagoon

Josef.95,

I'm not a systemd hater. I'm a retired avionics systems engineer and I recognise poor/lacking design when I see it.

Such examples of shoddy engineering are to be avoided, wherever they occur. Systemd just happens to be a very visible example.

----------

## Josef.95

 *Josef.95 wrote:*   

> From /usr/lib/modules-load.d/virtualbox.conf it would not load automatically (on Gentoo).

 

Supplement:

This is not right :-/ 

sorry, ignore this please.

Yes, this new automatically load behavior is added from Bug 490988

for systemd and OpenRC.Last edited by Josef.95 on Thu Jul 27, 2017 3:10 pm; edited 1 time in total

----------

## josephg

 *Josef.95 wrote:*   

> Yes, this new automatically load behavior is added from Bug 490988
> 
> for systemd and OpenRC.

 

thanks for digging this  :Smile:  so this is what started it! i see that bugfix is specifically for systemd, but i don't use systemd. this shouldn't impact systems without systemd.

 *Pacho Ramos wrote:*   

> +  17 Nov 2013; Pacho Ramos <pacho@gentoo.org> +files/virtualbox.conf,
> 
> +  virtualbox-modules-4.3.2.ebuild:
> 
> +  Install a modules-load.d file to load modules automatically on systemd
> ...

 

openrc method of auto loading modules is different: http://wiki.gentoo.org/wiki/Kernel_Modules#Automatic_loading

has openrc been broken by systemd? that systemd method works on my gentoo without systemd. and i have to use a systemd fix to stop it, which also works.Last edited by josephg on Sun Jul 30, 2017 2:53 am; edited 3 times in total

----------

## i4dnf

openrc has unfortunately been "broken" by its current "developer" to behave like systemd in this and a couple of other cases.

https://github.com/OpenRC/openrc/commit/556dbff99d53cdcc00e6b1ec67e1679f72b6f284

https://github.com/OpenRC/openrc/commits/24010dcb483cf7284cd8a5db111ae63f0d4e1038/init.d/modules-load.in

On my system I have commented out the line triggering this  in /etc/init.d/modules

```

depend()

{

        use isapnp

        #want modules-load

        keyword -docker -lxc -openvz -prefix -systemd-nspawn -vserver

}
```

----------

## NeddySeagoon

i4dnf,

A few users have stayed with openrc-0.17 or older too.  I'm an openrc-0.17.

----------

## Josef.95

josephg,

a empty file in /etc/modules-load.d/ should work.

Example for virtualbox modules: 

```
mkdir /etc/modules-load.d

touch /etc/modules-load.d/virtualbox.conf
```

 (reboot)

This override the /usr/lib/modules-load.d/virtualbox.conf file with the same name.

This works fine on my OpenRC System :)

/edit

and systemd systems to.

----------

## josephg

 *i4dnf wrote:*   

> openrc has unfortunately been "broken" by its current "developer" to behave like systemd

 

 *NeddySeagoon wrote:*   

> A few users have stayed with openrc-0.17 or older too.  I'm an openrc-0.17.

 

what's the purpose of staying on the train, if it's not going where you want to go? if i want systemd behaviour, i'd just use systemd rather than try make openrc behave like systemd.

----------

## i4dnf

Maybe there should be more noise on this bug:

https://bugs.gentoo.org/show_bug.cgi?id=609312

----------

## NeddySeagoon

josephg,

I suppose I got to where I wanted to be, so I got off the train.

----------

## josephg

 *NeddySeagoon wrote:*   

> so I got off the train.

 

please don't  :Sad:  when good people leave.. not good for the world.

you're one of the best things that happened to me in gentoo!

----------

## BT

This "feature" can also cause kernel modules to be loaded twice: https://github.com/OpenRC/openrc/issues/98.

----------

## krinn

What is the point of loading modules in openrc from systemd's locations?

- first openrc is not systemd

- second, openrc handling of module is superior to systemd, both can just load module if you ask them to load a module (!) but openrc have conditional loading of module (modules_3.4="this" will load "this" only with a kernel 3.4)

- third, if i want to always load a module, i have no use of a module, that autoload module config file in an ebuild is a stupidity (and both for openrc and systemd). The main purpose of a module is to not load it, but load it when you want and need it.

You can also see in https://gitweb.gentoo.org/repo/gentoo.git/tree/app-emulation/virtualbox-modules/virtualbox-modules-5.0.40.ebuild

Because systemd users are too braindead to handle this?

```
 elog "If you are using systemd, please add \"vboxdrv\", \"vboxnetflt\","

   elog "\"vboxnetadp\" and \"vboxpci\" to:"

   elog "  /usr/lib/modules-load.d/virtualbox.conf"

```

For me, i don't care that much about /usr/lib/modules-load.d support in openrc as long as /etc/conf.d/modules remains (as long as williamh have no plans to remove it)

The real problem is virtualbox ebuild and any ebuild that per default install files to autoload the module.

With that mentality:

- ebuild will have <rc-update add "any initscript"> just because you have an init script in the ebuild

- any ebuild for an X application will just add it to autostart with X (you will really love autostart of libreoffice!)

----------

## NeddySeagoon

josephg,

Not the Gentoo train, the OpenRC train.  I did Old Fashioned Gentoo in response to udev being assimilated by systemd and the announcement that udev without systemd would be unsupported.

That hasn't happened yet.  I think the existence of eudev and its popularity has delayed that but its unlikely to have stopped it altogether.

My main desktop runs  Old Fashioned Gentoo with OpenRC-0.17.

All my x86/amd64 installs use OpenRC-0.17 and my Aarch64 install follows the tree.  There is enough to fiddle with on 64 bit Raspberry Pi anyway.

----------

## josephg

 *NeddySeagoon wrote:*   

> Not the Gentoo train, the OpenRC train.

 

*whew*

but i thought openrc was gentoo

 *NeddySeagoon wrote:*   

> My main desktop runs  Old Fashioned Gentoo with OpenRC-0.17.
> 
> All my x86/amd64 installs use OpenRC-0.17 and my Aarch64 install follows the tree.

 

may i ask why 0.17 specifically? i'm a bit late to this party.

and if not openrc, what else? i've looked at runit, even before gentoo. i like voidlinux.. a bit like arch, but better and more efficient imho. i tried runit on gentoo for a while but eventually gave up. some others talk up s6.. haven't really looked at it.

----------

## mv

The whole issue is just a simple a bug in the ebuild:

The pkg_postinst() message is plainly false, because users of current openrc are not suppossed to add anything to /etc/conf.d/modules for this ebuild.

I suggest to file a bug for this ebuild that this message be removed (or at least reformulated in a sense like: "If you use <sys-apps/openrc-0.21.7 ..." [The version number is just a guess - it would need to be looked up in which version the modules.d support was added]).

@krinn: You have to see it from the viewpoint of developers who write a general package, not for a particular distribution or init system. Just like in dozens of other cases like /etc/X11/xorg.conf.d, /etc/X11/ld.sd.conf.d, /etc/cron.d, /etc/xinet.d, /etc/pam.d/, ... they can just drop the corresponding file in the matching location instead of requiring the user to manually manipulate dozens config files. As an upstream developer, I can say that I am very happy that these standard locations have meanwhile been extended to modules. This is a sane standard and has nothing to do with systemd. For this reason, I also strongly doubt that /etc/conf.d/modules will ever go away from openrc: This is the way to install user modules in openrc (in constrast to modules.d which is as mentioned above is meant for upstream packages to drop in the modules required to function properly.)

@NeddySeagoon:

 *NeddySeagoon wrote:*   

> I also have
> 
> ```
> INSTALL_MASK="${INSTALL_MASK} /usr/lib/systemd *.la"
> ```
> ...

 

I agree with the opinion that it is a horrible hack. Unless you need every byte of disk space you have to admit that the reason for this hack is an expression of a political protest and not a technical matter: Nothing else but systemd will ever access the files in .../systemd/... (that's why this directory is called this way, isn't it?).

Of course, you are free to choose. Anyway, if you decide for it, I would also add /etc/systemd and /lib/systemd to this list (gentoo is about moving to the standard location /lib/systemd instead of the special gentoo-only variant /usr/lib/systemd).

I strongly suggest to remove the *.la from INSTALL_MASK: There are some packages which really do require the *.la files. Previously, I had removed the unneeded files on  a per-package basis in /etc/portage/env. Meanwhile, I call this function from my /etc/portage/bashrc (the latter happens automatically if you install portage-bashrc-mv, e.g. from the mv overlay).

----------

## NeddySeagoon

@josephg,

I was using openrc-0.17 at the time the addition of the nofail option was being discussed on the -dev ML.

The default was to be that if a local filesystem failed no mount, the boot would fail.

This default made a lot of people who missed the news item, OpenRC-0.18 localmount and netmount changes very unhapy when their remote servers failed to reboot.

Sometime later, the default "fail" option, introduced by OpenRC-0.18 was reverted to nofail, which was original behavior before the option existed.

I was unhappy about the design decision to break backwards compatibility, so stayed with openrc-0.17.  Once the change was reverted, I could have updated to a more recent version.

However, there have been other questionable systems design decisions since that time, which means I would need to pick my version carefully.

I might do that when I'm forced to update for some reason.

@mv,

Removing *.la files was a response many years ago to the cross build system using them for linking.  Since that time, Gentoo started to remove *.la fles that are not required anyway.

They contain absolute paths to the build hosts native libraries, which is a very bad thing when the intent is to link against an arm lib.

It was only ever intended to be a temporary fix. Heh, there is nothing as permanent as a temporary solution :)

I'm not sure I see the merger of systemd and openrc file locations as benignly as you. I agree with the upstream benefits. A single location for all these things.

Given the systemd appetite for assimilating things, the cynic in me sees this as the first step to systemd assimilating then destroying openrc. 

Embrace ... expand ... extinguish ... .   Where have I heard that before.  

That's another reason for staying with an openRC version prior to this merger. There is no technical basis for this decision ... yet. 

I'm less paranoid about systemd being snuck in behind my back than I was, so I am more likely to remove the /usr/lib/systemd from INSTALL_MASK= that to clean up the other small files its left on my system. 

I like your script for only keeping required *.la files. Thank you.

----------

## josephg

i thought the USE=systemd was for this very reason.. ie to add/remove any systemd stuff (files/locations/behaviour). why aren't gentoo devs using this for all affected packages?

----------

## mv

 *josephg wrote:*   

> i thought the USE=systemd was for this very reason.. ie to add/remove any systemd stuff (files/locations/behaviour).

 

The purpose of USE flags is explicitly not to prevent installation of small files. Their purpose is limited to installation of large files (or with a side effect), severe dependencies, or when the compiled binary is affected (e.g. because it links to some library or not).

----------

## krinn

 *mv wrote:*   

> @krinn: You have to see it from the viewpoint of developers who write a general package

 

No i have to see it like it need to be seen: from the point of the view of the user, or the sysadmin

It's because they seeing it from dev pov that this fail: oh my users are dumb ass and they will complains virtualbox doesn't work because they forget or are too dumb to load the modules: i will force these modules load for them then.

 *mv wrote:*   

> This is a sane standard and has nothing to do with systemd.

 

This is a systemd directory location, so it's totally related to systemd ; it's even more related to systemd because openrc already have module handling, you don't took and create a feature from systemd in openrc to enhance openrc, you duplicate a feature you already have there.

This is in no way a standard, it's not because you (in this case pottering) decide that your modules will be put in "somewhere" that "somewhere" is a standard.

If there's no standard, the per default assumption is that previous usage is the standard, and systemd is the most recent init ; so you can count any others as standard.

So you can claim it's standard for systemd but in no way claim it's standard ; sorry i'm not drinking that.

Can we keep this topic out of false argument for systemd supremacy? we have politics of systemd thread for that.

It's also totally related to systemd as my hostility to systemd made you assume i was hostile there "because it's related to systemd".

I'm hostile there, because dev put files in it when you didn't ask him to do so ; and because this could have an impact: i didn't test, but i'm pretty sure my system will be broken by such action, nvidia drivers is well known to hate any other drivers using the card, won't this happen after i reboot because a dev has decide my need to use virtualbox is my only and true need?

And even if, why would i bloat my system memory with virtualbox drivers i don't need?

That dev do that to systemd users too: don't force them (any users init, even systemd users) to load a module when you've been asked to install a package only.

josephg:

because they decide any packages that could have an unit for systemd will install the unit even if you don't use systemd.

that's kind of dirty, but it's also dirty for systemd users to my knowledge, as i think openrc init.d files are also install even user have systemd useflag and no use for them.

I have myself INSTALL_MASK="/usr/lib/systemd /etc/systemd" (thank you for the info mv, looks like i need to extend it with /lib/systemd soon)

I don't care any dev telling me my system could be broken by that, openrc is not systemd, if my system is broken because of that mask, i will filebug against openrc to fix that ; and the same devs keep warning you about that are well aware of this "problem", so if tomorrow openrc is broken because of that mask, it mean devs are well aware of it already, and they do it even knowing it ; which would raise this "problem" far over a simple bug, but to an attack.

----------

## josephg

 *mv wrote:*   

> The whole issue is just a simple a bug in the ebuild:
> 
> The pkg_postinst() message is plainly false, because users of current openrc are not suppossed to add anything to /etc/conf.d/modules for this ebuild.
> 
> I suggest to file a bug for this ebuild that this message be removed

 

i'm sorry, but i don't see gentoo/openrc standard as a bug. the message is just being explicit and informational, as expected.

 *mv wrote:*   

> You have to see it from the viewpoint of developers who write a general package, not for a particular distribution or init system.

 

in this case, the developers (of the ebuild?) do this for a particular init. nothing general or to do with any other init.

 *mv wrote:*   

>  *josephg wrote:*   i thought the USE=systemd was for this very reason.. ie to add/remove any systemd stuff (files/locations/behaviour). 
> 
> The purpose of USE flags is explicitly not to prevent installation of small files. Their purpose is limited to installation of large files (or with a side effect), severe dependencies, or when the compiled binary is affected (e.g. because it links to some library or not).

 

define small or large? i'm pretty sure your interpretation will widely vary with many other folks here.

and there is a side effect, because openrc is trying to behave like systemd and run stuff intended for systemd.

 *krinn wrote:*   

> because they decide any packages that could have an unit for systemd will install the unit even if you don't use systemd.
> 
> that's kind of dirty, but it's also dirty for systemd users to my knowledge, as i think openrc init.d files are also install even user have systemd useflag and no use for them.

 

if openrc files are installed, would systemd run such code? i don't believe so..

are you suggesting openrc useflag to get rid of dirty files for systemd users?

i probably wouldn't care too much about some small systemd text files, except that openrc wants to run this. and i didn't expect it! lord only knows what else is happening on my system without my knowledge  :Rolling Eyes: 

----------

## Fitzcarraldo

 *krinn wrote:*   

> because they decide any packages that could have an unit for systemd will install the unit even if you don't use systemd.
> 
> that's kind of dirty, but it's also dirty for systemd users to my knowledge, as i think openrc init.d files are also install even user have systemd useflag and no use for them.

 

Not that I agree with that approach either, but I had assumed it has been implemented that way so that the user would be able to switch back and forth between the two systems more easily if (s)he wanted to. Is that not the case? Because, if it isn't possible to switch back and forth, I can see no good reason for systemd files to be installed in a Gentoo installation using OpenRC or for OpenRC files to be installed in a Gentoo installation using systemd. What *is* the purpose of installing systemd files if the user has USE="-systemd", and what *is* the purpose of installing OpenRC files if the user has USE="systemd"? That's not a rhetorical question, I am perplexed by the whole thing.

----------

## krinn

 *Fitzcarraldo wrote:*   

> Is that not the case? Because, if it isn't possible to switch back and forth

 

No idea, i know only the openrc->systemd path is handle (because openrc is default and the path to goes systemd must exist from openrc->systemd).

Even if it's doable to revert from systemd->opernc, i'm not sure if a user would do that ; you don't get back from systemd, because it's too awesome! (i couldn't refrain myself, can this be taken just like it is ; a little joke rather than derail to systemd politics thread?)

I think the key to this is: no handling of systemd or -systemd useflag in all packages just for unit or init.d files.

Yeah, for me laziness drive this choice.

----------

## mv

 *josephg wrote:*   

> [i'm sorry, but i don't see that as a bug. that is the gentoo/openrc standard

 

No, it is not. If it is in load-modules.d it has nothing lost in conf.d/modules.

 *Quote:*   

> define small or large? i'm pretty sure your interpretation will widely vary with many other folks here.

 

Of course. That's why this policy is questionable and often a topic of discussion. However, it is gentoo policy developers agreed upon. If you do not agree, try to change the policy but don't shoot the messenger.

 *Quote:*   

> and there is a side effect, because openrc

 

There is the "side effect" that it works under openrc. Except that there is a wrong message printed.

----------

## josephg

 *mv wrote:*   

>  *josephg wrote:*   [i'm sorry, but i don't see that as a bug. that is the gentoo/openrc standard 
> 
> No, it is not. If it is in load-modules.d it has nothing lost in conf.d/modules.

 

so you're now saying that gentoo/openrc has changed policy to automagically run stuff from systemd locations like load-modules.d even on systems without systemd, even with load-modules service disabled on all runlevels?

----------

## Tony0945

 *josephg wrote:*   

> i thought the USE=systemd was for this very reason.. ie to add/remove any systemd stuff (files/locations/behaviour). why aren't gentoo devs using this for all affected packages?

  A very good question, isn't it?

----------

## mv

 *krinn wrote:*   

>  *mv wrote:*   @krinn: You have to see it from the viewpoint of developers who write a general package 
> 
> No i have to see it like it need to be seen: from the point of the view of the user, or the sysadmin

 

Which doesn't change anything for me: If I install a package, I expect it to be installed with a sane standard configuration (if possible). Of course, there might be very few packages for which this is not possible, but these should be exceptional. If you do not want to have this luxury: I suggest to use INSTALL_MASK="/etc /var" and read the full documentation of every package you install and adapt it to your needs and for every machine individually (or using some individually configured automation of your choice). I prefer to stay away from this redundant work and find it convenient to get the configuration and change it only if I do not agree with it.

 *Quote:*   

> oh my users are dumb ass and they will complains virtualbox doesn't work because they forget or are too dumb to load the modules: i will force these modules load for them then.

 

For me it is: Oh, my users will perhaps try whether my package is for them, without wanting to read tons of documentations before. And most likely my users do not want to wonder about strange error messages because the module needed to use my software is not loaded. Those exceptional users who want to install my software but do not intend to use it, are probably clever enough to read the standard documentation of the init system they are using to prevent the default loading of modules they do not desire.

 *Quote:*   

> This is a systemd directory location

 

No. It is not in any .../systemd/.. directory. In fact, it is a standard location like /etc/hostname or /etc/udev. Init systems can or cannot honour these 3 (and other) locations. I prefer init systems which do, but you are free to use other init system or patch your init system to not honour these files.

----------

## mv

 *josephg wrote:*   

> so you're now saying that gentoo/openrc has changed policy to automagically run stuff from systemd locations like load-modules.d

 

As I said (parallel to your posting): modules-load.d is not a systemd location. It is a general location with a general purpose.

And yes, openrc now supports this location. It does so by having in "modules" depend() on "want modules-load", so you have to change the latter if for some strange reason you want support for only conf.d/modules but not for all other distributions' standard location modules.load.d

----------

## Tony0945

 *mv wrote:*   

> ... but not for all other distributions' standard location modules.load.d

 

But all other distributions (with minor exceptions) require systemd. So you are saying Gentoo is a systemd dstribution and OpenRC is an aberration to be shoved off to the side. Supports my thesis that Gentoo should be forked into Gentoo and Gentoo.d

EDIT: spellingLast edited by Tony0945 on Sat Jul 29, 2017 4:52 pm; edited 1 time in total

----------

## mv

 *NeddySeagoon wrote:*   

> Given the systemd appetite for assimilating things, the cynic in me sees this as the first step to systemd assimilating then destroying openrc.

 

I think you overestimate the role of openrc. It is really not important to the systemd developers whether openrc does or does not support a new standard location of files.

And even if they do: ff openrc would stay retarded and refuses to support all new standards introduced since 2010 or so, they could (rightfully) hold it against openrc.

Yes, I see a huge difficulty that meanwhile new standards in init systems practically only have a chance to appear if the systemd developers agree to support them.

But this is even more a reason to support these standards (if they are sane, of course) instead of fighting them.

----------

## mv

 *Tony0945 wrote:*   

>  *mv wrote:*   ... but not for all other distributions' standard location modules.load.d 
> 
> But all other distributions (with minor exceptions) require systemd.

 

That's how support for this standard location is implemented on most distributions. Yes.  Exactly like support for /etc/hostname and /etc/udev is implemented on most distributions through systemd. So what? Do you intend to remove support for everything which on some distribution is implemented through systemd? Or support the standard only if it is supported also by a certain critical number of independent init systems? But how can you do the latter if you even complain if an init system decides to support such a new standard? The latter is the road to stagnancy.

----------

## josephg

 *mv wrote:*   

>  *krinn wrote:*   This is a systemd directory location 
> 
> No. It is not in any .../systemd/.. directory. In fact, it is a standard location like /etc/hostname or /etc/udev.

 

at the risk of repeating ourselves, you stand corrected sir. this is very much a systemd location. it is documented, and i can provide you references, or you can search systemd docs yourself.

standards happen when everyone agrees! everyone won't accept it as standard just because you say so, or systemd has decided it should be the standard everyone else should follow. no others claim to set standards for everyone else.. claiming that only your decisions can be the standards everyone else should follow is taking the choice away from others.. contrary to the Gentoo Philosophy imho

 *mv wrote:*   

>  *NeddySeagoon wrote:*   Given the systemd appetite for assimilating things, the cynic in me sees this as the first step to systemd assimilating then destroying openrc. 
> 
> I think you overestimate the role of openrc. It is really not important to the systemd developers whether openrc does or does not support a new standard location of files.
> 
> And even if they do: ff openrc would stay retarded and refuses to support all new standards introduced

 

i see a certain attitude from systemd proponents which make me very wary of encouraging them to be standard keepers. and the same goes for gnome too. remember how gnome got trashed by gnome2 which got trashed by gnome3.. betcha gnome4 will dump everything gnome3  :Razz:  i'm just waiting for systemd2

 *NeddySeagoon wrote:*   

> There is no technical basis for this decision ... yet.

 

----------

## mv

 *josephg wrote:*   

> it is documented, and i can provide you references, or you can search systemd docs yourself.

 

Of course, it is documented in systemd, because it is supported by systemd. As is /etc/hostname and /etc/udev and many other systemd-only and not systemd-only things.

 *Quote:*   

> standards happen when everyone agrees!

 

This never happens. By this ideal definition, there are no standards at all.

Reality is: there are formal standards and de-facto standards. Formal standards (across all groups of developers) almost do not exist in the computer world, an exception being perhaps POSIX and (already much less) FHS. And also these two react only after many years to what already has become the de-facto standard before. And moreover, several things included in these formal standards are sometimes de facto not honoured for various reasons.

 *Quote:*   

> i see a certain attitude from systemd proponents which make me very wary of encouraging them to be standard keepers

 

I completely agree. That's why I try to distinguish between systemd stuff and things which have become a de-facto standard since the large distributions have switched to systemd as sharp as possible. Of course, systemd fanboys are interested in blurring the boundaries: Everything useful developed since then should be attributed only to them.

Unfortunately, the fact is: If there is a good candidate for a de-facto standard which needs support from the boot system, it is currently (as long as the large distributions do use systemd) necessary to include it in systemd. So in reality, systemd developers already have the possibility of a negative veto. This is very sad. But it cannot be changed by simply rejecting any new feature just "because it is implemented in systemd". This would just play in their hands: It would increase the number of de-facto standards and useful features only supported by systemd. If just enough useful features are ignored by all other init systems, it becomes impossible that large distributions will ever switch away again from systemd, and distributions not using systemd will need even more hand-work and patches. An example of this hand-work is exactly the (meanwhile wrong) pkg_postinst message from this thread: Having to tell the user to edit a config-file, because the package manager is unable to install a sane default config in a standard location, is not a good thing.

----------

## krinn

 *mv wrote:*   

> Having to tell the user to edit a config-file, because the package manager is unable to install a sane default config in a standard location, is not a good thing.

 

THIS IS NOT A SANE DEFAULT CONFIG!!!

It is a file to force loading module on a system when the sysadmin didn't ask you do to that.

 *mv wrote:*   

> If I install a package, I expect it to be installed with a sane standard configuration (if possible). 

 

That's why we have etc-update "mechanism", you install your default config file to help user, BUT without fucking his own config ; and user thru etc-update decide on the action to take.

And this work.

 *mv wrote:*   

> For me it is: Oh, my users will perhaps try whether my package is for them, without wanting to read tons of documentations before. And most likely my users do not want to wonder about strange error messages because the module needed to use my software is not loaded.

 

And your reaction to "oh my users want try a package" is "oh let's fuck their system"...

For ones that want a real saner setup, as it will really fix the issue

```
INSTALL_MASK="/usr/lib/modules-load.d"
```

----------

## mv

 *krinn wrote:*   

> THIS IS NOT A SANE DEFAULT CONFIG!!!

 

It makes no sense to repeat the arguments. Most people will consider it sane to have the system configured such that they can run the programs they installed. Some people don't.

 *Quote:*   

> That's why we have etc-update "mechanism"

 

Yes, every distribution has its own horrible hacks to deal with the /etc hell. None of these hacks is good, and all are horrible to store such that the system and local changes can be reproduced reliably.

The best solution to the issue has come up with udev and is now fortunately also standard in many tools, meanwhile:

The default configs are stored in the main tree (so they can easily be used and included), and only modifications to them are stored in /etc. "Modifications" can include complete removal by means of linking to /dev/null.

This happens to be the case with modprobe.d, moidules-load.d, udev, and hopefully soon for much more. This mechanism is obvious, local changes to the defaults are clearly visible, and it is trivial to reset things to the default configuration. Moreover, it is trivial to change distribution-wide default.

 *Quote:*   

> you install your default config file to help user

 

Do you? Which default config file do you install for a kernel module?

I went through this nightmare before: I had first written code in the ebuild which attempts to add the module to /etc/conf.d/modules. This  is necessarily is an ugly hack, since it is of course not possible to make a reliably working suggestion how to modify the possibly complex shell code in /etc/conf.d/modules.

But it was far worse: After each openrc bump/re-emerge the defaults wanted to reset, and then again after each emerge of my package, etc-update reported changes. The reason is simply that there is a (config) file collision between two packages. Such things simply must always be avoided.

End of the story is that the etc-mechanism simply is too hackish and cannot be sanely used for files which need to be extended by several packages.

My decision in the end was to hack into /etc/conf.d/modules a mechanism to add support for /etc/load-modules.d. How glad I was, that this mechanism was then finally implemented in openrc, even in the sane way mentioned above.

 *Quote:*   

> For ones that want a real saner setup, as it will really fix the issue
> 
> ```
> INSTALL_MASK="/usr/lib/modules-load.d"
> ```
> ...

 

Yep: Everybody who wants full manual control - in particular, to read the full documentation of every package he installs and enjoys wondering why things are not working out-of-the-box if he has missed a small remark somewhere - should do this. And  do not forget to also add /etc to INSTALL_MASK so that nothing can ever mess up your configs.

Edit: typos and:

I agree that it might be a good idea to add /lib/modules-load.d, /lib/modprobe.d, and /lib/tmpfiles.d (and /usr/lib/...) to CONFIG_PROTECT. Unfortunately, the etc-update mechanism does not inform you about new files there (when you install new packages). Perhaps somebody wants to send a feature request for portage to support such a thing.Last edited by mv on Sun Jul 30, 2017 9:38 am; edited 1 time in total

----------

## josephg

 *mv wrote:*   

> The default configs are stored in the main tree (so they can easily be used and included), and only modifications to them are stored in /etc.

 

 *mv wrote:*   

> This mechanism is obvious, local changes to the defaults are clearly visible, and it is trivial to reset things to the default configuration. Moreover, it is trivial to change distribution-wide default.

 

i like this bit! so a system with no modifications should have an almost empty /etc?

and where do you draw the line? if you do everything systemd does, you might as well use systemd!

----------

## mv

 *josephg wrote:*   

> i like this bit! so a system with no modifications should have an almost empty /etc?

 

If all tools would follow this format, then yes. I have no statistic about their number.

 *Quote:*   

> and where do you draw the line?

 

I cannot tell people what to do. Every upstream decides what he considers sane, and every ebuild author decides whether he follows upstream or patches things out.

My "personal" line (in my projects and my setups) is: The modprobe.d, load-modules.d, tmpfiles.d, and udev directories are great (together with the above mechanism), and these are the only things which I consider to be independent from systemd (in fact, all 4 of them also do have at least 1 independent implementation I am aware of). I do not like most  of the other systemd concepts; especially, I do not consider the whole dbus mechanism secure enough to run on my system. I have installed and configured systemd for possible booting/usage in emergency cases, though.

----------

## NeddySeagoon

josephg,

Then we would need an openrc USE, so that small openrc files were not installed on systemd systems.

We are talking about a number of small files so the HDD space is not important.

There was a debate on the -dev ML.  The consensus was that by not installing these files it made the transitions between init systems more difficult, since to get them, you ned to reinstall the packages that provided them.

Providing you allow both sets of small files to install, its possible to dual boot openrc and systemd in the same install by changing the init= in the boot loader configuration.

mv was correct that 

```
INSTALL_MASK="/usr/lib/modules-load.d"
```

is more a political statement now than it was a few years ago when it was set.

I'm more aware signs of encroachment by systemd that I was when I created that entry.  If I knew then what I know now, I probably wouldn't have bothered.

----------

## josephg

 *NeddySeagoon wrote:*   

> Then we would need an openrc USE, so that small openrc files were not installed on systemd systems.

 

and why not.. isn't that the purpose of useflags? particularly when those (small or not) files affect system behaviour.

 *NeddySeagoon wrote:*   

> There was a debate on the -dev ML.  The consensus was that by not installing these files it made the transitions between init systems more difficult, since to get them, you ned to reinstall the packages that provided them.

 

 *josephg wrote:*   

> if openrc files are installed, would systemd run such code? i don't believe so..

 

 *NeddySeagoon wrote:*   

> Providing you allow both sets of small files to install, its possible to dual boot openrc and systemd in the same install by changing the init= in the boot loader configuration.

 

who in their right mind would install both openrc and systemd to switch back and forth in any type of production (server/desktop/laptop/mobile/etc) environment? the stable target should always be a production environment. i can see this need for testers perhaps, but not for general users. devs can do whatever with -9999 or even perhaps ~arch.

 *Fitzcarraldo wrote:*   

>  *krinn wrote:*   because they decide any packages that could have an unit for systemd will install the unit even if you don't use systemd.
> 
> that's kind of dirty, but it's also dirty for systemd users to my knowledge, as i think openrc init.d files are also install even user have systemd useflag and no use for them. 
> 
> Not that I agree with that approach either, but I had assumed it has been implemented that way so that the user would be able to switch back and forth between the two systems more easily if (s)he wanted to. Is that not the case? Because, if it isn't possible to switch back and forth, I can see no good reason for systemd files to be installed in a Gentoo installation using OpenRC or for OpenRC files to be installed in a Gentoo installation using systemd. What *is* the purpose of installing systemd files if the user has USE="-systemd", and what *is* the purpose of installing OpenRC files if the user has USE="systemd"? That's not a rhetorical question, I am perplexed by the whole thing.

 

 *josephg wrote:*   

>  *mv wrote:*   This mechanism is obvious, local changes to the defaults are clearly visible, and it is trivial to reset things to the default configuration. Moreover, it is trivial to change distribution-wide default. 
> 
> i like this bit! so a system with no modifications should have an almost empty /etc?
> 
> and where do you draw the line?

 

 *mv wrote:*   

> My "personal" line (in my projects and my setups) is: The modprobe.d, load-modules.d, tmpfiles.d, and udev directories are great (together with the above mechanism)

 

and why stop there.. you can't say this is a better way only for these four directories? why not go further.. let's streamline the whole process and have as gentoo policy to install config files only in /lib, and leave /etc for sysadmin configs only!

but please do this overtly, and not covertly sneaking in things contrary to existing policy or docs. discussion helps. it is possible to arrive at consensus, unless some think that all others are haters/greybeards/etc. if not, there's always forks to live and let live!

 *Tony0945 wrote:*   

> So you are saying Gentoo is a systemd dstribution and OpenRC is an aberration to be shoved off to the side. Supports my thesis that Gentoo should be forked into Gentoo and Gentoo.d

 Last edited by josephg on Mon Aug 07, 2017 7:58 am; edited 1 time in total

----------

## mv

 *josephg wrote:*   

>  *NeddySeagoon wrote:*   Then we would need an openrc USE, so that small openrc files were not installed on systemd systems. 
> 
> and why not.. isn't that the purpose of useflags?

 

As already mentioned: No. Since quite a while gentoo has set up the policy that USE must not be introduced to force/omit the installation of small files. Typical examples mentioned in this connection were zsh-completion and bash-completion files which are now usually installed unconditionally (although a few packages still have these USE-flags; maybe these are bugs or the flags serve a different purpose here.)

Since this policy was cited so often (in many bugs and on devlist), I was quite sure it is on a prominent place in the developer's hand book. Howver, the best I could find in the moment is this:  *https://devmanual.gentoo.org/general-concepts/use-flags/ wrote:*   

> The usage of a USE flag should not control runtime dependencies when the package does not link to it.

  This is not explicitly mentioning small files, but at least implicitly said files would require a dependency. Maybe somebody can help out with a better referemce?

 *Quote:*   

> let's streamline the whole process and have as gentoo policy to install config files only in /lib, and leave /etc for sysadmin configs only!

 

This is not something which a small distribution like gentoo can decide: For Gentoo, this must come from the upstream packages.

In theory, a distribution could patch every single package which uses a config-file in /etc, but in practice this would exceed Gentoo's available manpower. Maybe Debian or Redhat have such a policy - I don't know. They would both have the manpower, and moreover, for them it might mean more than just convenience, since starting with in empty /etc is what they might want to achieve for virtual machines and containers.

 *Quote:*   

> discussion helps. it is possible to arrive at consensus

 

Not really. Even in POSIX many people do not agree with the decisions being made. And in POSIX things are relatively simple since a consensus can be "forced" by voting. There is no institution which can describe free software how to behave. This can be viewed as good or bad. Concerning any standardization, it is a severe obstacle. On the other hand, "official" standardization can also be a severe ball and chain as can be seen with PMS and how it prevents new useful features being added (new EAPI's practically do not appear due to bikeshedding etc.)

Edit: Added my finiding about the USE-flag policy.

----------

## josephg

 *mv wrote:*   

>  *Quote:*   let's streamline the whole process and have as gentoo policy to install config files only in /lib, and leave /etc for sysadmin configs only! 
> 
> This is not something which a small distribution like gentoo can decide: For Gentoo, this must come from the upstream packages.

 

i'm talking about gentoo packages.

----------

## mv

 *josephg wrote:*   

>  *mv wrote:*    *Quote:*   let's streamline the whole process and have as gentoo policy to install config files only in /lib, and leave /etc for sysadmin configs only! 
> 
> This is not something which a small distribution like gentoo can decide: For Gentoo, this must come from the upstream packages. 
> 
> i'm talking about gentoo packages.

 

That's not a large number of packages. Essentially, I think openrc is the only gentoo project which uses default configuration files (besides eudev which already uses said mechanism). Well, there is also /etc/dispatch-conf.conf and /etc/etc-update, but I think that's it. Portage itself already uses kind of such a mechanism by storing the defaults in /usr/share/portage/config and allowing override.

----------

## steveL

 *mv wrote:*   

> @krinn: You have to see it from the viewpoint of developers who write a general package

   *krinn wrote:*   

> No i have to see it like it need to be seen: from the point of the view of the user, or the sysadmin

   *mv wrote:*   

> Which doesn't change anything for me: If I install a package, I expect it to be installed with a sane standard configuration (if possible). Of course, there might be very few packages for which this is not possible, but these should be exceptional. If you do not want to have this luxury: I suggest to use INSTALL_MASK="/etc /var" and read the full documentation of every package you install and adapt it to your needs and for every machine individually (or using some individually configured automation of your choice). I prefer to stay away from this redundant work and find it convenient to get the configuration and change it only if I do not agree with it.

  This is a completely specious argument that has nothing to do with automagically enabling modules just because they are installed (with some package.)

 *Quote:*   

> Oh, my users will perhaps try whether my package is for them, without wanting to read tons of documentations before. And most likely my users do not want to wonder about strange error messages because the module needed to use my software is not loaded. Those exceptional users who want to install my software but do not intend to use it, are probably clever enough to read the standard documentation of the init system they are using to prevent the default loading of modules they do not desire.

  Funny, above I could swear you were talking about distributions and installers.

These kinds of choices are down to the distribution; 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.

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.

 *Quote:*   

> it is a standard location like /etc/hostname or /etc/udev. Init systems can or cannot honour these 3 (and other) locations. I prefer init systems which do, but you are free to use other init system or patch your init system to not honour these files.

  More specious nonsense.

Please, stop disparaging people who disagree with you, using arguments you have made up and assigned to them.

Just because someone runs around shouting that something is a "standard", and we should all get used to it, does not make it so.

Though much is usually inferred from the fact that they need to promote it so heavily, instead of letting it speak for itself.

----------

## josephg

 *steveL wrote:*   

> 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.

 *steveL wrote:*   

> 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.
> ...

 

and that's why we have docs. those who come to gentoo do so for very specific reasons, least of all plug-and-pray!Last edited by josephg on Tue Aug 01, 2017 1:28 am; edited 3 times in total

----------

## steveL

 *josephg wrote:*   

> 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

```
# 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

 *i4dnf wrote:*   

> 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.

 *i4dnf wrote:*   

> 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?Last edited by josephg on Wed Aug 02, 2017 9:54 am; edited 1 time in total

----------

## i4dnf

Hmm, openrc manual (man openrc-run) says the !modules-load  should work.

i.e in /etc/conf.d/modules

```
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.

```
$ cat /etc/conf.d/modules

rc_want="!modules-load"
```

i4dnf, thank you! this is perfect  :Smile:  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

```
# 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

 *josephg wrote:*   

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

 

 *man openrc-run wrote:*   

> 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:

 *http://wiki.manjaro.org/index.php?title=using_OpenRC,_an_alternative_to_systemd#Module_auto-loading wrote:*   

> 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

```

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_3.0/fhs-3.0.html#etcHostspecificSystemConfiguration

 *Quote:*   

> /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]

 

 *Quote:*   

> 
> 
> /usr/lib : Libraries for programming and packages
> 
> 4.6.1. Purpose
> ...

 

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

 *Naib wrote:*   

> 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).

 *Naib wrote:*   

> 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.

----------

