Summary: | sys-apps/openrc should not silently modify runlevels on update | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Andrew Church <achurch+gentoo> |
Component: | Current packages | Assignee: | OpenRC Team <openrc> |
Status: | RESOLVED INVALID | ||
Severity: | normal | CC: | hydrapolic |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Andrew Church
2019-04-08 10:47:55 UTC
Are you aware that you can edit /etc/conf.d/bootmisc to change the behavior of the bootmisc service? There is a setting there that will make boot misc not wipe the tmp directory. Is there anything else bootmisc does you don't want it to do? (In reply to William Hubbs from comment #1) > Are you aware that you can edit /etc/conf.d/bootmisc to change the > behavior of the bootmisc service? (In reply to Andrew Church from comment #0) > since I had not modified the default /etc/conf.d/bootmisc (having opted to > instead remove the service and replace it with a custom service of my own) In other words, yes, I am and was aware. > Is there anything else bootmisc does you don't want it to do? In the past I believe bootmisc was removing other files I did not want it to remove. That no longer seems to be the case (whether because of changes to bootmisc or changes to my system configuration), but on principle, I don't want a service which by its very name does unspecified miscellaneous tasks; I'd rather have specific scripts for each task. (reverting subject) I don't disagree that it would be useful to break bootmisc into separate services by function, but that's not what I'm getting at here. My issue is that openrc silently modifies configuration data in a CONFIG_PROTECTed directory (namely /etc), rather than suggesting the change and allowing the user to apply it or not, such as with etc-update. I would have run into the same problem if bootmisc had already been broken into multiple services, I had removed the "wipe /tmp" service, and openrc had silently added it back as happened with bootmisc here. I grant that the structure of /etc/runlevels, in which the presence or absence of a file controls openrc's behavior, makes it difficult to use the existing ._cfg0000 method. Perhaps runlevel configuration could be put in a plain text configuration file which is then processed by another script to update /etc/runlevels? Sort of like env-update, but generating symlinks from the configuration file instead of merging multiple file fragments into a single one. The concern with what you are suggesting is that bootmisc is a required service in openrc. As shown below, some services order themselves around it during boot. whubbs@whubbs1 init.d $ pwd /home/whubbs/repos/github.com/openrc/openrc/init.d whubbs@whubbs1 init.d $ grep -i bootmisc *.in consolefont.in: after hotplug bootmisc modules devd.in: after bootmisc moused.in: after bootmisc network.in: after bootmisc clock nscd.in: after bootmisc powerd.in: after bootmisc rarpd.in: after bootmisc save-keymaps.in: after bootmisc clock keymaps save-termencoding.in: after bootmisc clock termencoding sysctl.in: before bootmisc logger syslogd.in: after bootmisc clock whubbs@whubbs1 init.d $ This is why I re-install it when you upgrade. From my pov, I have only two choices. Mark this bug invalid since you are customizing required services or maybe come up with something that works for both of us by breaking down the boot misc service and figuring out what the relationship should be with the new services and fixing the dependencies. What do you think? Why are you so focused on bootmisc? I only brought it up as an example; there have been other (though less destructive) cases of this in the past with other services, both within and outside OpenRC. The issue I'm trying to address is the more general issue of configuration changes, not specifically that bootmisc deleted my data (and I was able to recover most of it from backup, for the record). I perhaps should not have called out OpenRC specifically in this bug and rather directed it to Portage. What do you think? No, there is not a portage bug here; portage is behaving correctly. OpenRC has a specific list of services it expects to run in the boot runlevel; they are depended on by other services. That is why we install them, I was just explaining that, following your bootmisc example. If you remove bootmisc, you break our default boot order because other services order themselves around boot misc. Someone on the dev chat channel suggested this, and thinking about it, it would probably be the safest way to make this happen. Whatever you do, you need a "bootmisc" service because of dependencies in other init.d service scripts. If you really want to customize what bootmisc does in ways not allowed by the conf.d file, I recommend rewriting the /etc/init.d/bootmisc service script and ignoring any updates to it in the future. The same thing would apply to any other OpenRC services you want to rewrite. Can we please just forget about bootmisc? Let's call it a service "xyzzy" installed by some separate (non-OpenRC) package. I should be able to review the configuration change of "adding service xyzzy to the default runlevel" before it is applied in /etc/runlevels, but currently I can't. That's what I'm trying to get at here. (And yes, I'm aware that there don't appear to be any packages currently in portage which do this. There have been in the past, and there could be in third-party overlays.) CONFIG_PROTECT protects files and symlinks that are already installed. it can't protect something that isn't there, so if you are removing a runlevel symlink completely that is why it is getting re-installed silently. Also, by default, it doesn't protect things that are not owned by a package. If you want to change that default, see the FEATURES settings in man 5 make.conf, and you get to keep the pieces. In Gentoo itself, if any packages other than openrc and udev-init-scripts ever add things to your runlevels, I would say that is a bug against the ebuilds. Most of the time packages should not be doing this. OpenRC and udev-init-scripts are exceptions because they are considered critical for booting if they are installed. We do not have any control over what happens in third party overlays, so I do not consider them part of this discussion. If the Gentoo position is that non-critical services should never be added automatically and addition of critical services should not be subject to user confirmation, I'll accept that and work around it on my system. It sounds like what you are asking for is for CONFIG_PROTECT to work even if a file isn't installed to begin with. Is that right? Not necessarily. That's what it would end up being given how /etc/runlevels is currently implemented, in that the presence of a file in a runlevel directory causes a change in behavior, but my focus is specifically on the runlevel configuration. If, for example, runlevels were implemented as a text configuration file listing the services active in each runlevel, the regular CONFIG_PROTECT logic would apply, and that would be fine with me too. |