[Bug 1029129] New: rpm: drop support for DISABLE_RESTART_ON_UPDATE/DISALBLE_STOP_ON_REMOVAL from /etc/sysconfig/service
http://bugzilla.suse.com/show_bug.cgi?id=1029129 Bug ID: 1029129 Summary: rpm: drop support for DISABLE_RESTART_ON_UPDATE/DISALBLE_STOP_ON_REMOVAL from /etc/sysconfig/service Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem Assignee: bnc-team-screening@forge.provo.novell.com Reporter: fbui@suse.com QA Contact: qa-bugs@suse.de Found By: --- Blocker: --- Hi, Those 2 global options are used in /etc/sysconfig/services. DISABLE_RESTART_ON_UPDATE=yes, disable the restart of *any* services during package updates which can lead to weak system. IMHO, we shouldn't give the possibility to the user to shoot himself in the foot by providing/suggesting a way to prevent the whole system from being updated properly. In the case where a specific package needs to turn off the "restart on update" or the "stop on removal" features, due to limitation (for instance dbus-1 doesn't support restart at all), then the package can already use some mechanism (Restart=no in the unit file, ...) in its specfile. But that should be disabled (by maintainers) for specific packages only which have good reasons to do so, no turned off globally. Hence I would propose to remove these 2 knobs. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1029129 Franck Bui <fbui@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|bnc-team-screening@forge.pr |mls@suse.com |ovo.novell.com | -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1029129 http://bugzilla.suse.com/show_bug.cgi?id=1029129#c6 --- Comment #6 from Michael Schröder <mls@suse.com> --- Adding the flags was done on request by our SLES customers, I don't think we should now suddenly remove them. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1029129 http://bugzilla.suse.com/show_bug.cgi?id=1029129#c8 Michael Schröder <mls@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |kukuk@suse.com --- Comment #8 from Michael Schröder <mls@suse.com> --- The customer absolutly didn't want a forces restart if an update was installed. I don't remember the exact details, maybe Thorsten knows. I find the idea to remove it "just because someone can shot himself in the foot" a bit strange. One of the principles of linux is that to give users enough rope to hang themselfs ;) -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1029129 http://bugzilla.suse.com/show_bug.cgi?id=1029129#c9 --- Comment #9 from Thorsten Kukuk <kukuk@suse.com> --- (In reply to Michael Schröder from comment #8)
The customer absolutly didn't want a forces restart if an update was installed. I don't remember the exact details, maybe Thorsten knows.
Don't remove that! I don't remember either why customers want this, but: when it was broken the last time, we got immeaditly a lot of complains from customers. So customers are really using this. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1029129 http://bugzilla.suse.com/show_bug.cgi?id=1029129#c10 --- Comment #10 from Franck Bui <fbui@suse.com> --- (In reply to Michael Schröder from comment #8)
I find the idea to remove it "just because someone can shot himself in the foot" a bit strange. One of the principles of linux is that to give users enough rope to hang themselfs ;)
Not sure you can call it "one of the principles of linux"... it might apply to rpm but I don't think you can/should generalize this principle to all projects out there (fortunately) ;) -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1029129 http://bugzilla.suse.com/show_bug.cgi?id=1029129#c11 --- Comment #11 from Franck Bui <fbui@suse.com> --- (In reply to Michael Schröder from comment #8)
The customer absolutly didn't want a forces restart if an update was installed.
It's sad that the reasons have been forgotten because IMHO strong arguments are needed to justify an option to allow possibly broken updates. And do we still want to "offer" such options for openSUSE users ? Isn't it possible to deprecate them and remove them for SLE13 ? Thanks. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1029129 http://bugzilla.suse.com/show_bug.cgi?id=1029129#c23 Michael Schröder <mls@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #23 from Michael Schröder <mls@suse.com> --- I'm closing this for now. Please discuss on the mailing lists. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1029129 https://bugzilla.suse.com/show_bug.cgi?id=1029129#c24 Franck Bui <fbui@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|WONTFIX |--- --- Comment #24 from Franck Bui <fbui@suse.com> --- So I'm reopening this bug as it's finally went through a jira request, see SLE-8968. Regarding SLE it's not been approved yet by PMs but at least it's been agreed that there's no point in keeping those two variables in Factory (and this bug is targeting Factory only). Also an announcement was sent to factory mailing list, see https://lists.opensuse.org/opensuse-factory/2020-09/msg00089.html Therefore can you please reconsider the request ? -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1029129 https://bugzilla.suse.com/show_bug.cgi?id=1029129#c25 --- Comment #25 from Michael Schröder <mls@suse.com> --- Factory is gonna be SLE-16 in the future, so I don't really get that point. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1029129 https://bugzilla.suse.com/show_bug.cgi?id=1029129#c26 Franck Bui <fbui@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |needinfo?(kukuk@suse.com) --- Comment #26 from Franck Bui <fbui@suse.com> --- Then your package will need to handle this SLE specificity. I'm not sure to understand the prob, various packages need to handle SLE and Factory differently for some parts even if Factory served as base for SLE. That said I'm not sure we have to advertise these 2 variables in SLE. We could still support them silently for SLE but users don't need to see them documented in /etc/sysconfig. @Thorsten, I asked you that already in JIRA, but don't you think we should drop DISABLE_RESTART_ON_UPDATE too from /etc/sysconfig (and from yast2 too) so that no one would be tempted to use them ? Of course systemd rpm macros will still support DISABLE_RESTART_ON_UPDATE as we already discussed. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1029129 https://bugzilla.suse.com/show_bug.cgi?id=1029129#c27 --- Comment #27 from Michael Schröder <mls@suse.com> --- I think you're missing one of the points of Factory: it's meant as a testbed for the next SLE. Therefore we want the difference between SLE and openSUSE to be as small as possible. Think of that openSUSE Jump effort, which aims to reuse binary packages from SLE in openSUSE. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1029129 https://bugzilla.suse.com/show_bug.cgi?id=1029129#c28 Thorsten Kukuk <kukuk@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(kukuk@suse.com) | --- Comment #28 from Thorsten Kukuk <kukuk@suse.com> --- (In reply to Franck Bui from comment #26)
@Thorsten, I asked you that already in JIRA, but don't you think we should drop DISABLE_RESTART_ON_UPDATE too from /etc/sysconfig (and from yast2 too) so that no one would be tempted to use them ?
If nobody finds the variable, we will get all the L3 again that this feature is missing with the next SLE version. Doesn't make much sense to me. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1029129 https://bugzilla.suse.com/show_bug.cgi?id=1029129#c29 --- Comment #29 from Franck Bui <fbui@suse.com> --- (In reply to Thorsten Kukuk from comment #28)
If nobody finds the variable, we will get all the L3 again that this feature is missing with the next SLE version. Doesn't make much sense to me.
We already agreed on the fact that these variables are a poor workaround for preventing some 3rd party applications to not be restarted during update, right ? So advertising them in both yast2 and /etc/sysconfig and pretending that this setting is fully supported as we currently do is misleading IMHO. In contrary I think we should hide them until a customer does ask for it and in this case we can first see whether this can be avoided and if not explicitly state that this is a bad option to choose. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1029129 https://bugzilla.suse.com/show_bug.cgi?id=1029129#c30 --- Comment #30 from Thorsten Kukuk <kukuk@suse.com> --- (In reply to Franck Bui from comment #29)
We already agreed on the fact that these variables are a poor workaround for preventing some 3rd party applications to not be restarted during update, right ?
No, we did not agreed on that, quite the contrary, I always said that there are valid use cases for this and that this is not a poor workaround and not a bad design of the application. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1029129 https://bugzilla.suse.com/show_bug.cgi?id=1029129#c31 --- Comment #31 from Franck Bui <fbui@suse.com> --- Ok if you think that disabling the restart of all packages installed on the system, resulting in a system running in an incoherent state (without speaking about the security fixes not being applied and the rest) then fine, I completely misunderstood you and we should continue exposing the variables as if it's something sane. But now, how can we proceed from there ? At least I'm sure that we decided to drop the support for these variables for Factory so they should be dropped from /etc/sysconfig and yast but apparently rpm from is used by all SLE distros [1] and Michael Schröder wants to keep them it identical. [1] I don't see how this can be possible given the fact that each distro I looked run a different version of rpm. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1029129 https://bugzilla.suse.com/show_bug.cgi?id=1029129#c32 --- Comment #32 from Michael Schröder <mls@suse.com> --- I never said that, do not make up things. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1029129 https://bugzilla.suse.com/show_bug.cgi?id=1029129#c33 --- Comment #33 from Franck Bui <fbui@suse.com> --- (In reply to Michael Schröder from comment #32)
I never said that, do not make up things.
Then I was probably mislead by your following comment:
Think of that openSUSE Jump effort, which aims to reuse binary packages from SLE in openSUSE.
AFAIK SLE binary packages are (going to be) reused by openSUSE Leap only so I'm not sure to understand which point you tried to make since this request is about Factory. And the fact that Leap will inherit its binary packages from Factory doesn't mean that next major version of SLE will have to be the same as Factory, does it ? Factory will have some divergences with next major version of SLE - some shortcomings have been introduced in SLE somehow and we have to keep them in SLE for backward compat reasons. Deprecating those stuff in SLE takes a while (here we have a good example) and it's nearly impossible for some cases. But that doesn't mean that we shouldn't improve Factory OTOH. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1029129 https://bugzilla.suse.com/show_bug.cgi?id=1029129#c34 --- Comment #34 from Michael Schröder <mls@suse.com> --- My point is the openSUSE:Factory will be SLE16 at one point, so we should not remove functionality required for SLES. Factory is supposed to be a testbed for SLES, so we should diverge as little as possible. That doesn't mean we should not remove broken things. It's just that we need to make sure that we don't remove things that are required by the SLES customers. (Of course it's also ok to offer them a better way to do what they want.) As for DISABLE_RESTART_ON_UPDATE, my impression was that this functionality is required by our sles customers. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1029129 https://bugzilla.suse.com/show_bug.cgi?id=1029129#c35 --- Comment #35 from Franck Bui <fbui@suse.com> --- (In reply to Michael Schröder from comment #34)
My point is the openSUSE:Factory will be SLE16 at one point, so we should not remove functionality required for SLES. Factory is supposed to be a testbed for SLES, so we should diverge as little as possible.
I agree with this in general but "as little as possible" doesn't mean "shoud not diverge". There're exceptions (tmpfs on /tmp, persistent naming scheme to list a few of them in systemd) and I think this is one of them. As pointed out serveral times already this functionality is badly designed and is unsafe, hence should not be proposed to TW/Factory users and IMHO should not be advertised in SLE neither. We only keep this for SLE because we have to keep backward compat for customers. Anyway, if you still want to keep them in sysconfig regardless of whether they're supported or not then that's your decision. I took time to initiate a discussion in JIRA, where we agreed on removing them in Factory, made sure that no openSUSE user relies on them, let you know that support for these variables will be removed from Factory... so I'm done. Feel free to close it as WONTFIX. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1029129 https://bugzilla.suse.com/show_bug.cgi?id=1029129#c36 Michael Schröder <mls@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution|--- |WONTFIX --- Comment #36 from Michael Schröder <mls@suse.com> --- As Leap16 will be bases on SLE16 you'll end up adding support for them back again. So I really do not understand your point. Anyway, I don't care. Closing with WONTFIX. -- You are receiving this mail because: You are on the CC list for the bug.
participants (2)
-
bugzilla_noreply＠novell.com -
bugzilla_noreply＠suse.com