After updating openrc to 0.41.2 and rebooting, I was quite disturbed to see the startup sequence say it was wiping my (persistent) /tmp despite my having explicitly removed the bootmisc service from all runlevels. It appears that the update silently re-added bootmisc to the boot runlevel, and 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), I got the default behavior of having my /tmp wiped. I believe it would be less potentially data-destructive to not silently modify the user's runlevels during a version update, at least in the case when those runlevels are not in a default state. I can see an argument for automatic changes if, for example, a service FOO has part of its behavior split out to a separate service BAR; if FOO is part of some runlevel by default *and* if the user has not removed it from that runlevel, it would make sense to then automatically add BAR to its designed runlevel. But otherwise I would argue that the proper behavior would be to notify the user of the proposed changes and let the user choose to apply them or not, as is done for other CONFIG_PROTECTed paths. emerge --info (note that /etc/runlevels is not in CONFIG_PROTECT_MASK): Portage 2.3.62 (python 3.6.8-final-0, default/linux/amd64/17.0, gcc-8.3.0, glibc-2.27-r6, 4.16.14-gentoo x86_64) ================================================================= System uname: Linux-4.16.14-gentoo-x86_64-Intel-R-_Core-TM-_i7-4770S_CPU_@_3.10GHz-with-gentoo-2.6 KiB Mem: 8113760 total, 3072812 free KiB Swap: 4028500 total, 4028500 free Timestamp of repository gentoo: Thu, 28 Mar 2019 14:45:01 +0000 Head commit of repository gentoo: ca4ced9d501ce173cf1cf50e5dbb8a919ff26b75 sh bash 4.4_p23-r1 ld GNU ld (Gentoo 2.32 p1) 2.32.0 app-shells/bash: 4.4_p23-r1::gentoo dev-java/java-config: 2.2.0-r4::gentoo dev-lang/perl: 5.28.0::gentoo dev-lang/python: 2.7.16::gentoo, 3.6.8::gentoo dev-util/cmake: 3.14.0::gentoo dev-util/pkgconfig: 0.29.2::gentoo sys-apps/baselayout: 2.6-r1::gentoo sys-apps/openrc: 0.41.2::gentoo sys-apps/sandbox: 2.17::gentoo sys-devel/autoconf: 2.13-r1::gentoo, 2.69-r4::gentoo sys-devel/automake: 1.11.6-r3::gentoo, 1.15.1-r2::gentoo, 1.16.1-r1::gentoo sys-devel/binutils: 2.32::gentoo sys-devel/gcc: 8.3.0::gentoo sys-devel/gcc-config: 2.0::gentoo sys-devel/libtool: 2.4.6-r5::gentoo sys-devel/make: 4.2.1-r4::gentoo sys-kernel/linux-headers: 4.16-r2::gentoo (virtual/os-headers) sys-libs/glibc: 2.27-r6::gentoo Repositories: gentoo location: /usr/portage sync-type: rsync sync-uri: rsync://rsync.jp.gentoo.org/gentoo-portage priority: -1000 sync-rsync-verify-metamanifest: no sync-rsync-verify-max-age: 24 sync-rsync-verify-jobs: 1 sync-rsync-extra-opts: --omit-dir-times --exclude=.git --no-human-readable crossdev location: /var/lib/crossdev masters: gentoo local vmware priority: 0 steam-overlay location: /var/lib/layman/steam-overlay masters: gentoo priority: 1 sunrise location: /var/lib/layman/sunrise masters: gentoo priority: 2 vmware location: /var/lib/layman/vmware masters: gentoo priority: 3 local location: /usr/local/portage masters: gentoo priority: 4 Installed sets: @steam, @system ACCEPT_KEYWORDS="amd64 ~amd64" ACCEPT_LICENSE="* -@EULA AdobeFlash-11.x D1X" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-O2 -march=x86-64 -mtune=core-avx-i -mmmx -msse -msse2 -pipe -fno-strict-aliasing" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/dev /etc /usr/lib64/libreoffice/program/sofficerc" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/ssl/certs /etc/terminfo" CXXFLAGS="-O2 -march=x86-64 -mtune=core-avx-i -mmmx -msse -msse2 -pipe -fno-strict-aliasing" DISTDIR="/usr/portage/distfiles" EMERGE_DEFAULT_OPTS="--misspell-suggestions=n --autounmask=n --quiet-build=n --changed-deps-report=n" ENV_UNSET="DBUS_SESSION_BUS_ADDRESS DISPLAY GOBIN PERL5LIB PERL5OPT PERLPREFIX PERL_CORE PERL_MB_OPT PERL_MM_OPT XAUTHORITY XDG_CACHE_HOME XDG_CONFIG_HOME XDG_DATA_HOME XDG_RUNTIME_DIR" FCFLAGS="-O2 -pipe" FEATURES="assume-digests binpkg-docompress binpkg-dostrip binpkg-logs collision-protect distlocks ebuild-locks fixlafiles merge-sync multilib-strict news preserve-libs protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync" FFLAGS="-O2 -pipe" GENTOO_MIRRORS="http://ftp.iij.ad.jp/pub/linux/gentoo" LDFLAGS="-Wl,-O1 -Wl,--as-needed" LINGUAS="" MAKEOPTS="" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_EXTRA_OPTS="--omit-dir-times --exclude=.git --no-human-readable" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --omit-dir-times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --exclude=/.git" PORTAGE_TMPDIR="/tmp" USE="aac alsa amd64 apng berkdb cjk cli crypt cxx dri dv dvd fortran gdbm gif iconv ipv6 joystick jpeg jpeg2k lame libtirpc live mad mp3 multilib ncurses nptl nptlonly ogg openmp png pv3 quicktime readline scanner sdl ssl theora tiff truetype unicode vdpau vorbis vpx win32codecs x264 xanim xinerama zlib" ABI_X86="32 64" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" APACHE2_MODULES="authn_core authz_core socache_shmcb unixd actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CALLIGRA_FEATURES="karbon sheets words" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" CPU_FLAGS_X86="mmx mmxext sse sse2" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock isync itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf skytraq superstar2 timing tsip tripmate tnt ublox ubx" INPUT_DEVICES="keyboard mouse" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" LLVM_TARGETS="AArch64 ARM X86" NETBEANS_MODULES="apisupport cnd groovy gsf harness ide identity j2ee java mobility nb php profiler soa visualweb webcommon websvccommon xml" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php5-6 php7-1" POSTGRES_TARGETS="postgres9_5 postgres10" PYTHON_SINGLE_TARGET="python3_6" PYTHON_TARGETS="python2_7 python3_6" RUBY_TARGETS="ruby24" SANE_BACKENDS="genesys" USERLAND="GNU" VIDEO_CARDS="nvidia" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account" Unset: CC, CPPFLAGS, CTARGET, CXX, INSTALL_MASK, LANG, LC_ALL, PORTAGE_BINHOST, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS
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.
