move restart-on-update to posttrans
Did anyone already explore the potential pitfalls of moving "restart on update" from %postun to %posttrans? There are two bugs with the current approach: First, having "restart on update" handling in %service_del_postun gives control to the old and potentially broken package. This alone should already be enough reason to change the flow of events. Second, the current approach makes it practically impossible to remove empty configuration files from the rpm packages. There are already a number of packages which have code like this: %pre test -f /etc/%{name}.conf.rpmsave && mv -v /etc/%{name}.conf.rpmsave /etc/%{name}.conf.rpmsave.old %posttrans test -f /etc/%{name}.conf.rpmsave && mv -v /etc/%{name}.conf.rpmsave /etc/%{name}.conf This will fail for configuration files required by daemons which will be restarted via 'systemctrl try-restart' in the %postun of the old package. Since the removed config is renamed to *.rpmsave prior %postun, and renamed back after the 'try-restart' in %posttrans, the daemon will find no config file. Some of the daemons start without a config, which means the daemon runs with its default configuration. Other daemons will fail to restart due to the lack of config file. The actual state whether a systemd service was running is lost, no way to attempt another restart in %posttrans. I think the following steps are required to get out of this bad situation: - all packages with a %service_del_postun/_without_restart need to get a %service_add_posttrans/_without_restart into their %posttrans. For packages without existing %posttrans the change will look like this, to make sure they remain compatible: %if %{defined service_add_posttrans} %posttrans %service_add_posttrans %{name}.service %endif Packages with a %postrans: %posttrans %if %{defined service_add_posttrans} %service_add_posttrans %{name}.service %endif - once all packages in Factory have received the change, adjust the package which owns %service_del_postun/%service_add_posttrans and actually carry out the bugfix: * %service_add_pre will rename /etc/sysconfig/services:DISABLE_RESTART_ON_UPDATE= to a new, to-be-found variable name. * %service_add_pre will set /etc/sysconfig/services:DISABLE_RESTART_ON_UPDATE= to yes so that the old, expanded "%_restart_on_update" does no damage anymore in the existing %postun scripts * %service_del_postun will lose the code which does 'systemctrl try-restart' * %service_add_posttrans will do the 'systemctrl try-restart', hopefully based on a better %_restart_on_update. The current one does 'exit 0' ... - adjust yast to deal with the renamed DISABLE_RESTART_ON_UPDATE= - adjust documentation, describe why the change had to be done Olaf
On Monday 2020-12-14 10:10, Olaf Hering wrote:
Did anyone already explore the potential pitfalls of moving "restart on update" from %postun to %posttrans?
I do not think there ought to be any. After all, you are just delaying the restart. Which is similar (in upgrade semantics) as not restarting the service at all.
Olaf Hering <olaf@aepfle.de> writes:
Did anyone already explore the potential pitfalls of moving "restart on update" from %postun to %posttrans?
There is one catch: if there are %posttrans scriptlets in a package, then libzypp will invoke rpm with `--noposttrans` [1] which also prevents %transfiletrigger scriptlets from firing. Zypper then invokes the collected posttrans scriptlets after the transaction, but it never invokes the transaction file triggers. Cheers, Dan Footnotes: [1] https://bugzilla.opensuse.org/show_bug.cgi?id=1041742#c1 -- Dan Čermák <dcermak@suse.com> Software Engineer Development tools SUSE Software Solutions Germany GmbH Maxfeldstr. 5 90409 Nuremberg Germany (HRB 36809, AG Nürnberg) Managing Director: Felix Imendörffer
Am Mon, 14 Dec 2020 11:37:15 +0100 schrieb Olaf Hering <olaf@aepfle.de>:
Am Mon, 14 Dec 2020 11:19:19 +0100 schrieb Dan Čermák <dcermak@suse.com>:
%transfiletrigger I had no idea such thing exists.
How are these things actually ordered, would this even be able to solve the issue? As shown earlier, the "*.rpmsave" handling needs to be done with %pre+%posttrans. This means these triggers must run after %posttrans, because otherwise the 'try-restart' will fail as it does now. Olaf
On Mon, 2020-12-14 at 11:19 +0100, Dan Čermák wrote:
Olaf Hering <olaf@aepfle.de> writes:
Did anyone already explore the potential pitfalls of moving "restart on update" from %postun to %posttrans?
There is one catch: if there are %posttrans scriptlets in a package, then libzypp will invoke rpm with `--noposttrans` [1] which also prevents %transfiletrigger scriptlets from firing. Zypper then invokes the collected posttrans scriptlets after the transaction, but it never invokes the transaction file triggers.
Which is why we do not accept transfiletriggers in Factory (except vagrant - where somehow it was missed) as zypp installs every RPM as an own transaction, in any case, transfiletrigger reacts exactly the same as filetrigger in our cases. The existing triggers can simply be converted at no lose of functionality (well, some loss - if somebody were to install using pure rpm, they might have a benefit; Possibly also if using DNF, not sure exactly how that does the transaction handling in openSUSE) Cheers, Dominique
On Mon, Dec 14, 2020 at 5:38 AM Dominique Leuenberger / DimStar <dimstar@opensuse.org> wrote:
On Mon, 2020-12-14 at 11:19 +0100, Dan Čermák wrote:
Olaf Hering <olaf@aepfle.de> writes:
Did anyone already explore the potential pitfalls of moving "restart on update" from %postun to %posttrans?
There is one catch: if there are %posttrans scriptlets in a package, then libzypp will invoke rpm with `--noposttrans` [1] which also prevents %transfiletrigger scriptlets from firing. Zypper then invokes the collected posttrans scriptlets after the transaction, but it never invokes the transaction file triggers.
Which is why we do not accept transfiletriggers in Factory (except vagrant - where somehow it was missed)
as zypp installs every RPM as an own transaction, in any case, transfiletrigger reacts exactly the same as filetrigger in our cases. The existing triggers can simply be converted at no lose of functionality (well, some loss - if somebody were to install using pure rpm, they might have a benefit; Possibly also if using DNF, not sure exactly how that does the transaction handling in openSUSE)
DNF uses librpm to run the transaction the same way RPM would. That is, all the packages are collected and installed in a single transaction, so transfiletrigger works correctly. File triggers (especially transfiletriggers) are used extensively in Fedora, Mageia, and OpenMandriva (where DNF is used), so I know that it works pretty much perfectly. Switching to DNF means the issue we have around transaction scriptlets goes away. -- 真実はいつも一つ！/ Always, there's only one truth!
On Mon, 2020-12-14 at 07:58 -0500, Neal Gompa wrote:
DNF uses librpm to run the transaction the same way RPM would. That is, all the packages are collected and installed in a single transaction, so transfiletrigger works correctly. File triggers (especially transfiletriggers) are used extensively in Fedora, Mageia, and OpenMandriva (where DNF is used), so I know that it works pretty much perfectly.
Switching to DNF means the issue we have around transaction scriptlets goes away.
And others appear :) DNF is interesting - and I started playing with it a bit too. What boggles me most so far is that we cannot just mix-and-match zypper and dnf. As a user, I have to either opt to use one (and not use the other) or maintain both in good stading order. What I mean, especially, is that the repo files/definitions are not being shared. If I was to switch to dnf, then all the yast tools might get the wrong info, as they are using the libzypp/zypper backend - whereas aas user I interact with dnf and use different repositories. yaiks. compare to zypper dup, dnf upgrade (somehow I assumed this would be the right thing for TW) does not offer downgrades. And the third thing I found while just running it in first trials that it wanted to install 'some -lang' packages (very few). on zypp, I have *-lang locked, so I am clear not to have any installed. as dnf does not use my locks (I guess) I was quite surprised that it only wanted to install like 3 -lang packages - of course honoring my zypp lock would be even better) This mail is not meant to dimish the work done in DNF - it seems to do what it advertises, something a bit better than zypper, somethings different, something possibly worse. Advertising it as 'the solution to all problems' is a bit premature though.
On Monday 2020-12-14 14:09, Dominique Leuenberger / DimStar wrote:
On Mon, 2020-12-14 at 07:58 -0500, Neal Gompa wrote:
DNF uses librpm to run the transaction the same way RPM would. That is, all the packages are collected and installed in a single transaction, so transfiletrigger works correctly. File triggers (especially transfiletriggers) are used extensively in Fedora, Mageia, and OpenMandriva (where DNF is used), so I know that it works pretty much perfectly.
Switching to DNF means the issue we have around transaction scriptlets goes away.
And others appear :)
Yeah, I'll just point back to https://lists.opensuse.org/opensuse-factory/2020-07/msg00066.html
On Mon, Dec 14, 2020 at 8:09 AM Dominique Leuenberger / DimStar <dimstar@opensuse.org> wrote:
On Mon, 2020-12-14 at 07:58 -0500, Neal Gompa wrote:
DNF uses librpm to run the transaction the same way RPM would. That is, all the packages are collected and installed in a single transaction, so transfiletrigger works correctly. File triggers (especially transfiletriggers) are used extensively in Fedora, Mageia, and OpenMandriva (where DNF is used), so I know that it works pretty much perfectly.
Switching to DNF means the issue we have around transaction scriptlets goes away.
And others appear :)
DNF is interesting - and I started playing with it a bit too. What boggles me most so far is that we cannot just mix-and-match zypper and dnf. As a user, I have to either opt to use one (and not use the other) or maintain both in good stading order. What I mean, especially, is that the repo files/definitions are not being shared.
If I was to switch to dnf, then all the yast tools might get the wrong info, as they are using the libzypp/zypper backend - whereas aas user I interact with dnf and use different repositories. yaiks.
compare to zypper dup, dnf upgrade (somehow I assumed this would be the right thing for TW) does not offer downgrades.
And the third thing I found while just running it in first trials that it wanted to install 'some -lang' packages (very few). on zypp, I have *-lang locked, so I am clear not to have any installed. as dnf does not use my locks (I guess) I was quite surprised that it only wanted to install like 3 -lang packages - of course honoring my zypp lock would be even better)
This mail is not meant to dimish the work done in DNF - it seems to do what it advertises, something a bit better than zypper, somethings different, something possibly worse.
Advertising it as 'the solution to all problems' is a bit premature though.
I had intentionally not configured DNF to read /etc/zypp/repos.d by default because of how Zypper rewrites repo files every time it processed them into invalid repo files (with type=NONE, among others). That caused DNF to automatically expire its cache and stop working. I would *love* to unify configuration between the two, but fixing YaST and everything else zypp-based to do the right thing is a bit of a pain. I'd like to get everything using rpm-repos-openSUSE instead of installing repos itself through the product.xml, and somehow get Zypper to stop rewriting repo files every time it read them... -- 真実はいつも一つ！/ Always, there's only one truth!
On Mon, Dec 14, 2020 at 8:18 AM Neal Gompa <ngompa13@gmail.com> wrote:
On Mon, Dec 14, 2020 at 8:09 AM Dominique Leuenberger / DimStar <dimstar@opensuse.org> wrote:
On Mon, 2020-12-14 at 07:58 -0500, Neal Gompa wrote:
DNF uses librpm to run the transaction the same way RPM would. That is, all the packages are collected and installed in a single transaction, so transfiletrigger works correctly. File triggers (especially transfiletriggers) are used extensively in Fedora, Mageia, and OpenMandriva (where DNF is used), so I know that it works pretty much perfectly.
Switching to DNF means the issue we have around transaction scriptlets goes away.
And others appear :)
DNF is interesting - and I started playing with it a bit too. What boggles me most so far is that we cannot just mix-and-match zypper and dnf. As a user, I have to either opt to use one (and not use the other) or maintain both in good stading order. What I mean, especially, is that the repo files/definitions are not being shared.
If I was to switch to dnf, then all the yast tools might get the wrong info, as they are using the libzypp/zypper backend - whereas aas user I interact with dnf and use different repositories. yaiks.
compare to zypper dup, dnf upgrade (somehow I assumed this would be the right thing for TW) does not offer downgrades.
And the third thing I found while just running it in first trials that it wanted to install 'some -lang' packages (very few). on zypp, I have *-lang locked, so I am clear not to have any installed. as dnf does not use my locks (I guess) I was quite surprised that it only wanted to install like 3 -lang packages - of course honoring my zypp lock would be even better)
This mail is not meant to dimish the work done in DNF - it seems to do what it advertises, something a bit better than zypper, somethings different, something possibly worse.
Advertising it as 'the solution to all problems' is a bit premature though.
I had intentionally not configured DNF to read /etc/zypp/repos.d by default because of how Zypper rewrites repo files every time it processed them into invalid repo files (with type=NONE, among others). That caused DNF to automatically expire its cache and stop working.
I would *love* to unify configuration between the two, but fixing YaST and everything else zypp-based to do the right thing is a bit of a pain. I'd like to get everything using rpm-repos-openSUSE instead of installing repos itself through the product.xml, and somehow get Zypper to stop rewriting repo files every time it read them...
Eck, I hit the send button too soon... The analogue to zypper dist-upgrade is "dnf distro-sync", and the "dup" short command is an alias to "dsync" (the shorthand version of distro-sync subcommand). DNF does not normally autoremove packages it doesn't know about, though you can ask it to autoremove unused leaves at any time with "dnf autoremove". For locks, there's a DNF has "excludes" for that, and there's a versionlock plugin that lets you manage them similarly to zypper locks[1]. [1]: https://www.mankier.com/8/dnf-versionlock -- 真実はいつも一つ！/ Always, there's only one truth!
Dominique Leuenberger / DimStar <dimstar@opensuse.org> writes:
compare to zypper dup, dnf upgrade (somehow I assumed this would be the right thing for TW) does not offer downgrades.
Yes, because afaik `dnf upgrade` does the same[1] as a `zypper up` and will only offer you upgrades. What you actually want to run on Tumbleweed is `dnf distro-sync`, which is closer to `zypper dup`. Cheers, Dan Footnotes: [1] mostly the same -- Dan Čermák <dcermak@suse.com> Software Engineer Development tools SUSE Software Solutions Germany GmbH Maxfeldstr. 5 90409 Nuremberg Germany (HRB 36809, AG Nürnberg) Managing Director: Felix Imendörffer
Dominique Leuenberger / DimStar composed on 2020-12-14 14:09 (UTC+0100):
On Mon, 2020-12-14 at 07:58 -0500, Neal Gompa wrote:
Switching to DNF means the issue we have around transaction scriptlets goes away.
And others appear :)
DNF inherited most of the disadvantages of YUM. Its conglomeration of long-winded name plugins and accompanying suite of man pages is horrible. Its locking system is particularly frustrating compared to Zypper. Zypper's creators obviously were familiar with them, and avoided repeating them. I rarely use YaST* for software management. Zypper makes command line package management, and openSUSE, a pleasure. -- Evolution as taught in public schools, like religion, is based on faith, not on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/
Olaf Hering wrote:
[...] I think the following steps are required to get out of this bad situation: - all packages with a %service_del_postun/_without_restart need to get a %service_add_posttrans/_without_restart into their %posttrans.
I'd love to see us phasing out those scriptlets in favor of file triggers. Esp for systemd services the situation with the scriptlets in all of %pre,%post,%preun and %postun is way too complex and annoying for packagers already. It should be enough for a package to drop the service file in the right location, all the rest can be handled by the system. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer HRB 36809 (AG Nürnberg)
Olaf Hering wrote:
Am Mon, 14 Dec 2020 13:10:15 +0100 schrieb Ludwig Nussel <ludwig.nussel@suse.de>:
I'd love to see us phasing out those scriptlets in favor of file triggers.
Is this a realistic goal? The bug referenced in that other email left this question unanswered AFAICS.
Normal, per package file triggers work fine. So at least the current behavior of the scriptlets could be reimplemented as triggers. To be able to execute something at the end of the transaction as you suggested, a bit more creativity would be needed. Eg a combination of file triggers collecting information about changes and a regular posttrans script. Or maybe threaten to use the old and crappy /var/adm/update-scripts again. Haven't researched the options myself yet. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer HRB 36809 (AG Nürnberg)
Hi Olaf, Olaf Hering <olaf@aepfle.de> writes:
Did anyone already explore the potential pitfalls of moving "restart on update" from %postun to %posttrans?
Apparently Zbigniew had a similar idea for Fedora, only leveraging transaction file triggers instead (which we unfortunately cannot use as already discussed): https://fedoraproject.org/wiki/Changes/Restart_services_at_end_of_rpm_transa... Cheers, Dan -- Dan Čermák <dcermak@suse.com> Software Engineer Development tools SUSE Software Solutions Germany GmbH Maxfeldstr. 5 90409 Nuremberg Germany (HRB 36809, AG Nürnberg) Managing Director: Felix Imendörffer
Am Wed, 16 Dec 2020 10:08:43 +0100 schrieb Dan Čermák <dcermak@suse.com>:
transaction file triggers
This other idea is about moving the "restart" around, which is unrelated to what needs to be fixed for SUSE: we need to remove files below /etc from packages, which requires to preserve modified files that where marked as %config. A brief search gave no hints about the ordering of these "triggers". In other words: will the 'mv' happen before the 'try-restart'? Olaf
Olaf Hering <olaf@aepfle.de> writes:
Am Wed, 16 Dec 2020 10:08:43 +0100 schrieb Dan Čermák <dcermak@suse.com>:
transaction file triggers
This other idea is about moving the "restart" around, which is unrelated to what needs to be fixed for SUSE: we need to remove files below /etc from packages, which requires to preserve modified files that where marked as %config. A brief search gave no hints about the ordering of these "triggers".
If I understand https://github.com/rpm-software-management/rpm/blob/5ce2b5e3121aa07eb1ccf2bc... correctly, then first %transfiletriggerun are run, then %posttrans, then %transfiletriggerpostun and at last %transfiletriggerin. I am not sure how exactly the %posttrans scriptlets are ordered, but my guess from https://github.com/rpm-software-management/rpm/blob/5ce2b5e3121aa07eb1ccf2bc... is that they are run in the same order that the packages are installed/upgraded. This all of course only applies if you use rpm/librpm to run these scriptlets, which afaik is not done by zypper. Maybe Michael and/or Benjamin can shed some light here? Cheers, Dan -- Dan Čermák <dcermak@suse.com> Software Engineer Development tools SUSE Software Solutions Germany GmbH Maxfeldstr. 5 90409 Nuremberg Germany (HRB 36809, AG Nürnberg) Managing Director: Felix Imendörffer
Am Wed, 16 Dec 2020 10:50:47 +0100 schrieb Dan Čermák <dcermak@suse.com>:
first %transfiletriggerun are run, then %posttrans, then %transfiletriggerpostun and at last %transfiletriggerin.
If that is true, %posttrans could do the 'mv', and '%transfiletriggerin' does the 'restart'? If we touch it anyway we have to make sure the old package does nothing in all its '%*uninstall' scripts during package update. Olaf
Olaf Hering <olaf@aepfle.de> writes:
Am Wed, 16 Dec 2020 10:50:47 +0100 schrieb Dan Čermák <dcermak@suse.com>:
first %transfiletriggerun are run, then %posttrans, then %transfiletriggerpostun and at last %transfiletriggerin.
If that is true, %posttrans could do the 'mv', and '%transfiletriggerin' does the 'restart'?
We could if zypper would allow to have %posttrans and %transfiletriggerin, but it will not execute the transaction file trigger in the presence a %posttrans. Ordinary file triggers will probably not work here as they are afaik run as part of the rpm transaction. Cheers, Dan -- Dan Čermák <dcermak@suse.com> Software Engineer Development tools SUSE Software Solutions Germany GmbH Maxfeldstr. 5 90409 Nuremberg Germany (HRB 36809, AG Nürnberg) Managing Director: Felix Imendörffer
Olaf Hering <olaf@aepfle.de> writes:
Am Wed, 16 Dec 2020 10:08:43 +0100 schrieb Dan Čermák <dcermak@suse.com>:
transaction file triggers This other idea is about moving the "restart" around, which is unrelated to what needs to be fixed for SUSE: we need to remove files below /etc from packages, which requires to preserve modified files that where marked as %config. A brief search gave no hints about the ordering of these "triggers".
If I understand https://github.com/rpm-software-management/rpm/blob/5ce2b5e3121aa07eb1ccf2bc... correctly, then first %transfiletriggerun are run, then %posttrans, then %transfiletriggerpostun and at last %transfiletriggerin.
I am not sure how exactly the %posttrans scriptlets are ordered, but my guess from https://github.com/rpm-software-management/rpm/blob/5ce2b5e3121aa07eb1ccf2bc... is that they are run in the same order that the packages are installed/upgraded.
This all of course only applies if you use rpm/librpm to run these scriptlets, which afaik is not done by zypper. Maybe Michael and/or Benjamin can shed some light here? Currently the transfiletrigger are not executed by zypper because we are installing each rpm package separately collecting the posttrans scripts by using a feature that disables them and instead prints which scripts would have been run. RPM has not yet a feature to detect the transfiletriggers that would've been executed, sadly the previously mentioned feature disables the
Am 16.12.20 um 10:50 schrieb Dan Čermák: them completely.
Cheers,
Dan
-- Benjamin Zeller <bzeller@suse.de> Systems Programmer SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuremberg, Germany Tel: +49-911-74053-0; Fax: +49-911-7417755; https://www.suse.com/ (HRB 36809, AG Nürnberg) Managing Director: Felix Imendörffer
participants (8)
-
Benjamin Zeller -
Dan Čermák -
Dominique Leuenberger / DimStar -
Felix Miata -
Jan Engelhardt -
Ludwig Nussel -
Neal Gompa -
Olaf Hering