[opensuse-factory] Dropping support for DISABLE_RESTART_ON_UPDATE/DISABLE_STOP_ON_REMOVAL
Hi, This is to announce that we'll soon drop support for DISABLE_RESTART_ON_UPDATE and DISABLE_STOP_ON_REMOVAL variables defined in /etc/sysonfig/service. These variables allow users to prevent *all* daemons from being restarted while their configuration, plugins, libraries or whatever on disk they depend on have changed. This can lead to various inconsistencies and also prevent security updates from being applied. While a few packages might have good reasons to not be restarted (because they simply don't support it like it was the case for logind) this should be handled at package level and handled by the package maintainer but not turned off for all services (!) by users that might not fully understand the consequences. So unless someone comes up with a real use case, support for these variables will be dropped in a near future. Thanks. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wed, Sep 9, 2020 at 1:10 PM Franck Bui <fbui@suse.de> wrote:
Hi,
This is to announce that we'll soon drop support for DISABLE_RESTART_ON_UPDATE and DISABLE_STOP_ON_REMOVAL variables defined in /etc/sysonfig/service.
These variables allow users to prevent *all* daemons from being restarted while their configuration, plugins, libraries or whatever on disk they depend on have changed. This can lead to various inconsistencies and also prevent security updates from being applied.
While a few packages might have good reasons to not be restarted (because they simply don't support it like it was the case for logind) this should be handled at package level and handled by the package maintainer but not turned off for all services (!) by users that might not fully understand the consequences.
So unless someone comes up with a real use case, support for these variables will be dropped in a near future.
Can we please just use the upstream systemd rpm macros? Dropping these behaviors makes it so that there's little value in maintaining our horribly out of date fork of the macros. -- 真実はいつも一つ！/ Always, there's only one truth! -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 9/9/20 7:16 PM, Neal Gompa wrote:
Can we please just use the upstream systemd rpm macros? Dropping these behaviors makes it so that there's little value in maintaining our horribly out of date fork of the macros.
Sure but let's do that in a second step. BTW the SUSE variant macros will still perform an additional step compare to their upstream counterparts which consists in converting enablement states of the sysvinit scripts into systemd enablement symlinks. I've been told that this might be not necessary anymore as migrating from old distros based on SysV init system to systemd based distros may be not supported anymore... -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thu, Sep 10, 2020 at 3:55 AM Franck Bui <fbui@suse.de> wrote:
On 9/9/20 7:16 PM, Neal Gompa wrote:
Can we please just use the upstream systemd rpm macros? Dropping these behaviors makes it so that there's little value in maintaining our horribly out of date fork of the macros.
Sure but let's do that in a second step.
BTW the SUSE variant macros will still perform an additional step compare to their upstream counterparts which consists in converting enablement states of the sysvinit scripts into systemd enablement symlinks.
I've been told that this might be not necessary anymore as migrating from old distros based on SysV init system to systemd based distros may be not supported anymore...
It is possible to have systemd configured to handle this properly, we just never _did_ in openSUSE. But yes, we don't need this functionality anymore. I'm fine with doing this in as many steps as you want to go through, but I want to stop stumbling on things just randomly missing that I expect to exist. -- 真実はいつも一つ！/ Always, there's only one truth! -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wed, Sep 9, 2020 at 2:05 PM Franck Bui <fbui@suse.de> wrote:
will be dropped in a near future.
I only know about logind and dbus..apparently both have been either fixed or they refuse manual start/stop. I have used this misfeature for distribution upgrade via ssh to feel assured I'll never get kicked out by random software restarting or messing the current session. I am aware my feelings have no effect on reality :-D that is , upgrades can go wrong in many ways whether I do this or not. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 9/10/20 2:49 AM, Cristian Rodríguez wrote:
On Wed, Sep 9, 2020 at 2:05 PM Franck Bui <fbui@suse.de> wrote:
will be dropped in a near future.
I only know about logind and dbus..apparently both have been either fixed or they refuse manual start/stop.
I have used this misfeature for distribution upgrade via ssh to feel assured I'll never get kicked out by random software restarting or messing the current session. I am aware my feelings have no effect on reality :-D that is , upgrades can go wrong in many ways whether I do this or not.
yeah dbus does this via its service file now and has done so I believe since somewhere in SLE-12 restarting dbus while the system is running would break a number of things including packagekit. Docker is one that has also caused issues in the past, in one case restarting the service triggered a migration that took up to 18 hrs which is not really what sysadmins were expecting. I remember fixing that just for one version update I can't remember if I used writing to that file or just didn't call the macro's on one version update either way it was a temp fix for one version and is no longer in either the SLE-12 or SLE-15 codebases. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
participants (4)
-
Cristian Rodríguez -
Franck Bui -
Neal Gompa -
Simon Lees