On Fri, Oct 11, 2019 at 09:11:27 +0200, Arkadiusz Miśkiewicz wrote: >>> systemctl preset-all >>> >>> Should we call it in %post like docs say?
BTW which docs? >> I think it's too risky since we don't have enough real-life testing. > > So right now we end up with services that are not enabled with this > version of systemd that were enabled with earlier version (like getty > for tty1 etc). Where were they being enabled? I'm not following this package recently, and can't find any changes in %post*. > If not call it on upgrade then at least on initial install. Install should call preset indeed - this operation requires attention anyway. I remember fixing something around presets: http://git.pld-linux.org/gitweb.cgi?p=packages/rpm-build-macros.git;a=commitdiff;h=3303369cd82fe4c2d6297d60fec3272066a322c5 (fixed later in aa13c88c1160df49c87ad3d9586c0bc0b4b3bc5d) ...and I wonder if we could call on upgrade: systemctl preset-all --preset-mode=enable-only but personally I wouldn't be happy if upgrade enabled services I've previously disabled[*] - sometimes masking is inappropriate as it prevents manual service start. We must also remember about such cases: http://git.pld-linux.org/gitweb.cgi?p=packages/systemd.git;a=blob;f=systemd.spec;h=67896daaaafd484b51979edb48046d97d86ab5d0;hb=HEAD#l995 - wouldn't this disable everything (not distro-preset"ted" to on) after "preset-all"? Note the "default.preset" filename, i.e. without priority prefix, would be applied last (which is correct as the first match wins), but we do not provide preset files: $ ipoldek --skip-installed rsearch -f /systemd.\*\.preset$/ systemd-units-241-2.x86_64 zfs-0.8.1-1.x86_64 So I guess this would result in disabled ssh as well (yikes!) [*] "If no preset files exist, systemctl preset will enable all units that are installed by default" PS: had no time to add missing directories: /var/lib/systemd/journal-upload /var/log/journal/remote -- Tomasz Pala <go...@pld-linux.org> _______________________________________________ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en