[Bug 968405] New: xdm restarts the user session on update
http://bugzilla.suse.com/show_bug.cgi?id=968405 Bug ID: 968405 Summary: xdm restarts the user session on update Classification: openSUSE Product: openSUSE Tumbleweed Version: 2015* Hardware: Other OS: Other Status: NEW Severity: Major Priority: P5 - None Component: X.Org Assignee: xorg-maintainer-bugs@forge.provo.novell.com Reporter: tchvatal@suse.com QA Contact: xorg-maintainer-bugs@forge.provo.novell.com Found By: --- Blocker: --- When system during update is updating xdm it takes down restarts the graphical user session with everything in it. It seems like the try-restart is not nice in this case enough to simply wait for user to exit the session and just kills everything. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=968405 http://bugzilla.suse.com/show_bug.cgi?id=968405#c1 Egbert Eich <eich@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |systemd-maintainers@suse.de | |, | |xorg-maintainer-bugs@forge. | |provo.novell.com Assignee|xorg-maintainer-bugs@forge. |mls@suse.com |provo.novell.com | Flags| |needinfo?(systemd-maintaine | |rs@suse.de) --- Comment #1 from Egbert Eich <eich@suse.com> --- This is indeed correct and I don't think this behaviour has been there before. We do set 'export DISABLE_RESTART_ON_UPDATE=yes' as this this issue has been fixed with bsc#886641 already and I don't see any changes in xdm recently which may have broken this. So maybe there is an issue with the %postun macro? -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=968405 http://bugzilla.suse.com/show_bug.cgi?id=968405#c2 Michael Schröder <mls@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|mls@suse.com |xorg-maintainer-bugs@forge. | |provo.novell.com --- Comment #2 from Michael Schröder <mls@suse.com> --- Maybe, but it's definitely not a rpm bug. So assigning back to you... -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=968405 http://bugzilla.suse.com/show_bug.cgi?id=968405#c3 --- Comment #3 from Egbert Eich <eich@suse.com> --- I meant to say the %service_del_postun macro defined in /usr/lib/rpm/macros. The reason why DISABLE_RESTART_ON_UPDATE=yes has no effect at all is that this variable is set by a script /etc/sysconfig/services which is sourced before the variable is evaluated. Since the intended use of this variable is tantamount to not to execute %restart_on_update and thus %service_del_postun at all, let's remove this line entirely. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=968405 http://bugzilla.suse.com/show_bug.cgi?id=968405#c4 Egbert Eich <eich@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Egbert Eich <eich@suse.com> --- Submitted for X11:XOrg, Factory. MR ID for 13.2 and Leap 42.1: 361763 -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=968405 Egbert Eich <eich@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(systemd-maintaine | |rs@suse.de) | -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=968405 http://bugzilla.suse.com/show_bug.cgi?id=968405#c16 --- Comment #16 from Dr. Werner Fink <werner@suse.com> --- (In reply to Dominique Leuenberger from comment #14) /etc/sysconfig/services is the only true documentation: # Type: yesno ## Default: no # # Do you want to disable the automatic restart of services when # a new version gets installed? # DISABLE_RESTART_ON_UPDATE="no" ## Type: yesno ## Default: no # # Do you want to disable the automatic shutdown of services when # the corresponding package gets erased? # DISABLE_STOP_ON_REMOVAL="no" Don't know which wiki says something different here. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=968405 http://bugzilla.suse.com/show_bug.cgi?id=968405#c21 --- Comment #21 from Dr. Werner Fink <werner@suse.com> --- (In reply to Dominique Leuenberger from comment #18)
You're trying hard, aren't you?
Indeed I do! Beside this, the wiki has to be fixed! -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=968405 http://bugzilla.suse.com/show_bug.cgi?id=968405#c27 --- Comment #27 from Michael Schröder <mls@suse.com> --- I'm also in favor of checking another environment variable, e.g. DISABLE_RESTART_ON_UPDATE_OVERRIDE -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=968405 http://bugzilla.suse.com/show_bug.cgi?id=968405#c29 --- Comment #29 from Michael Schröder <mls@suse.com> --- (I wonder who came up with that export DISABLE_RESTART_ON_UPDATE idea. It never worked with the pre-systemd macros and only worked with systemd by mistake. The scriptlets always have to source the /etc/sysconfig/services file, which will overwrite the env var...) -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=968405 http://bugzilla.suse.com/show_bug.cgi?id=968405#c30 Olaf Hering <ohering@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |ohering@suse.com --- Comment #30 from Olaf Hering <ohering@suse.com> --- (In reply to Dominique Leuenberger from comment #28)
./xen/xen.spec:export DISABLE_RESTART_ON_UPDATE=yes
Nothing in xen-tools can be restarted, as long as there are active domUs and backends. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=968405 http://bugzilla.suse.com/show_bug.cgi?id=968405#c34 Dr. Werner Fink <werner@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(werner@suse.com) | --- Comment #34 from Dr. Werner Fink <werner@suse.com> --- IMHO a list of services which should not be restarted may added to /etc/sysconfig/services then this list can be used to be skip exactly this services from getting restarted. Currently there are xdm and other display managers ... maybe sshd, and some others .. xen? (In reply to Michael Schröder from comment #29) Even this can be avoided with some scripting ;) (In reply to Dominique Leuenberger from comment #23) Sorry but I prefere to get SLES and openSUSE in sync at this point. Even if this requires a veto from my side. We could also discuss about the defaults in /etc/sysconfig/services ... nevertheless for a security fix for e.g. postfix or any other network based daemon you really like to have a restart in case of an update. And this was the reason for this feature. And this is alos useful even for openSUSE based systems out there. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=968405 http://bugzilla.suse.com/show_bug.cgi?id=968405#c38 Michael Schröder <mls@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(mls@suse.com) | --- Comment #38 from Michael Schröder <mls@suse.com> --- guys, you're making this way too complicated. Introducing a new list is way too confusing. For our use cases it's much better to have the package know what to do. Please keep it simple. As for comment#32: yes, we do need this. Hijacking a already existing variable is a bad idea. We can also add a switch to the macros if you prefer this. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=968405 http://bugzilla.suse.com/show_bug.cgi?id=968405#c40 --- Comment #40 from Michael Schröder <mls@suse.com> --- The additional variable gives me the good feeling that it's not a bad hack. You can't override all the other sysconfig vars with the environment, so why should it be different in this case? -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=968405 http://bugzilla.suse.com/show_bug.cgi?id=968405#c41 --- Comment #41 from Michael Schröder <mls@suse.com> --- (But a macro option would be even more clean, I admit.) -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=968405 http://bugzilla.suse.com/show_bug.cgi?id=968405#c45 --- Comment #45 from Michael Schröder <mls@suse.com> --- Comment#42 and #43: Your macro change will also only take effect when the corresponding packages are released again, as the macros are already expanded in the binary packages. So I don't see any difference. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=968405 http://bugzilla.suse.com/show_bug.cgi?id=968405#c46 --- Comment #46 from Dr. Werner Fink <werner@suse.com> --- (In reply to Michael Schröder from comment #45) This is always true! -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=968405 http://bugzilla.suse.com/show_bug.cgi?id=968405#c47 --- Comment #47 from Dr. Werner Fink <werner@suse.com> --- Created attachment 667148 --> http://bugzilla.suse.com/attachment.cgi?id=667148&action=edit Small chnage which adds a rpm macro option as well as makes the DISABLE_RESTART_ON_UPDATE=1 or DISABLE_STOP_ON_REMOVAL=1 work as well -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=968405 http://bugzilla.suse.com/show_bug.cgi?id=968405#c48 --- Comment #48 from Dr. Werner Fink <werner@suse.com> --- (In reply to Dr. Werner Fink from comment #47) Maybe a notifier should be added as well as now the (super) user has to restart or stop the service! -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=968405 http://bugzilla.suse.com/show_bug.cgi?id=968405#c49 --- Comment #49 from Dominique Leuenberger <dimstar@opensuse.org> --- (In reply to Dr. Werner Fink from comment #47)
Created attachment 667148 [details] Small chnage which adds a rpm macro option as well as makes
the DISABLE_RESTART_ON_UPDATE=1 or DISABLE_STOP_ON_REMOVAL=1 work as well
I like the solution! - Let's make sure that we get this fully documented on what works (seems exporting the variable OR passing -d is fine) and which solution we prefer (presumably -d, but this will only work on openSUSE Tumbleweed and SLE12SP2) -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=968405 http://bugzilla.suse.com/show_bug.cgi?id=968405#c50 --- Comment #50 from Dominique Leuenberger <dimstar@opensuse.org> --- %_restart_check_systemctl \ - test "$DISABLE_RESTART_ON_UPDATE" = yes && exit 0 \ + test "$DISABLE_RESTART_ON_UPDATE" != no && exit 0 \ But as /etc/sysconfig/service is not yet sourced at that moment, ANY package not specifying it =no will NOT restart now (their value of DISABLE+RESTART_ON_UPDATE is "", not 'no' -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=968405 http://bugzilla.suse.com/show_bug.cgi?id=968405#c51 --- Comment #51 from Egbert Eich <eich@suse.com> --- (In reply to Michael Schröder from comment #45)
Comment#42 and #43: Your macro change will also only take effect when the corresponding packages are released again, as the macros are already expanded in the binary packages. So I don't see any difference.
Of course. For any package released after the broken macros was released it is too late. The difference is: when you change the semantics, you will have to notify each maintainer of a consumer of the macro of the change and make sure any possible update is properly serialized with the update to systemd-rpm-macros. Of course it would be possible to have both the new (macro option driven) and old deprecated env variable driven semantics around in parallel for a while. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=968405 http://bugzilla.suse.com/show_bug.cgi?id=968405#c52 --- Comment #52 from Michael Schröder <mls@suse.com> --- So DISABLE_RESTART_ON_UPDATE=0 will also disable the restart? Doesn't look like a good idea. (And I don't like that it looks at the environment, this means that the env of the person running rpm is used to check this as well. That's why I preferred the option...) -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=968405 http://bugzilla.suse.com/show_bug.cgi?id=968405#c53 --- Comment #53 from Egbert Eich <eich@suse.com> --- (In reply to Dominique Leuenberger from comment #50)
%_restart_check_systemctl \ - test "$DISABLE_RESTART_ON_UPDATE" = yes && exit 0 \ + test "$DISABLE_RESTART_ON_UPDATE" != no && exit 0 \
But as /etc/sysconfig/service is not yet sourced at that moment, ANY package not specifying it =no will NOT restart now (their value of DISABLE+RESTART_ON_UPDATE is "", not 'no'
Exactly. I did propose a patch in comment #33 which sources /etc/sysconfig/service but so far this has been ignored completely. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=968405 http://bugzilla.suse.com/show_bug.cgi?id=968405#c54 --- Comment #54 from Dr. Werner Fink <werner@suse.com> --- (In reply to Dominique Leuenberger from comment #50) In /etc/sysconfig/services there are clear declaration *what+ values are used: ## Path: System/Services ## Type: yesno ## Default: no ... sorry but if a sytem admin edits this without reading I can not help. And it should be clear that this works only for the case DISABLE_RESTART_ON_UPDATE=1 rpm -Uhv ... or DISABLE_RESTART_ON_UPDATE=1 zypper up ... -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=968405 http://bugzilla.suse.com/show_bug.cgi?id=968405#c55 --- Comment #55 from Dominique Leuenberger <dimstar@opensuse.org> --- (In reply to Egbert Eich from comment #53)
But as /etc/sysconfig/service is not yet sourced at that moment, ANY package not specifying it =no will NOT restart now (their value of DISABLE+RESTART_ON_UPDATE is "", not 'no'
Exactly. I did propose a patch in comment #33 which sources /etc/sysconfig/service but so far this has been ignored completely.
Maybe I should have given more context... the sourcing of /etc/sysconfig/services would happen right after.. so the approach is equal to what you proposed in comment 33... first check the 'env', then source and recheck the env variable (now coming from the file). The difference being: comment ee checked if DISABLE_RESTART_ON_UPDATE=yes && exit 0 and Werner's new solution doing DISABLE_RESTART_ON_UPDATE != no, which sounds very appealing at first, but fails, as outlined above, as unless specified by the package/user/anything else, the variable is not set at all. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=968405 http://bugzilla.suse.com/show_bug.cgi?id=968405#c56 --- Comment #56 from Dr. Werner Fink <werner@suse.com> --- (In reply to Michael Schröder from comment #52) I also prefere options ... nevertheless the environment variable is already described even if with value "1" instead of "yes". Beside this and with my change the option does override the environment variable. If the environment variable should win that more work has to done. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=968405 http://bugzilla.suse.com/show_bug.cgi?id=968405#c57 --- Comment #57 from Dominique Leuenberger <dimstar@opensuse.org> --- (In reply to Dr. Werner Fink from comment #54)
(In reply to Dominique Leuenberger from comment #50)
In /etc/sysconfig/services there are clear declaration *what+ values are used:
## Path: System/Services ## Type: yesno ## Default: no
... sorry but if a sytem admin edits this without reading I can not help. And it should be clear that this works only for the case
DISABLE_RESTART_ON_UPDATE=1 rpm -Uhv ...
or
DISABLE_RESTART_ON_UPDATE=1 zypper up ...
and what in case of simply: rpm -Uhv <package>? Sorry Werner: your script would not execute a restart of the service in this case, as UPDATE_ON_RESTART!=no is satisfied and the script exits. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=968405 http://bugzilla.suse.com/show_bug.cgi?id=968405#c58 --- Comment #58 from Dr. Werner Fink <werner@suse.com> --- (In reply to Dominique Leuenberger from comment #55) OK ... then something like test -n "$DISABLE_RESTART_ON_UPDATE" -a "$DISABLE_RESTART_ON_UPDATE" != no && exit 0 -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=968405 http://bugzilla.suse.com/show_bug.cgi?id=968405#c59 Egbert Eich <eich@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #667084|0 |1 is obsolete| | --- Comment #59 from Egbert Eich <eich@suse.com> --- Created attachment 667154 --> http://bugzilla.suse.com/attachment.cgi?id=667154&action=edit Fix using a macro argument while retaining the old semantics. How about this? It retains the old (deprecated) semantics but adds a command line argument. We could make the command line argument work both ways ie. override the user provided default setting altogether as well. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=968405 http://bugzilla.suse.com/show_bug.cgi?id=968405#c60 --- Comment #60 from Egbert Eich <eich@suse.com> --- Created attachment 667263 --> http://bugzilla.suse.com/attachment.cgi?id=667263&action=edit Patch for %_restart_check_systemctl using macro argument Proposal using a macro argument. %_stop_check_systemctl can be handled likewise. It's ugly but generates only the script code we need. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=968405 http://bugzilla.suse.com/show_bug.cgi?id=968405#c61 Egbert Eich <eich@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #667154|0 |1 is obsolete| | Attachment #667263|0 |1 is obsolete| | --- Comment #61 from Egbert Eich <eich@suse.com> --- Created attachment 667293 --> http://bugzilla.suse.com/attachment.cgi?id=667293&action=edit Full patch for macros.systemd -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=968405 http://bugzilla.suse.com/show_bug.cgi?id=968405#c62 Dr. Werner Fink <werner@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #667148|0 |1 is obsolete| | CC| |eich@suse.com Flags| |needinfo?(eich@suse.com) --- Comment #62 from Dr. Werner Fink <werner@suse.com> --- Created attachment 667365 --> http://bugzilla.suse.com/attachment.cgi?id=667365&action=edit Yet an other change (In reply to Egbert Eich from comment #61) Hmmm ... what do you think about this? -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=968405 http://bugzilla.suse.com/show_bug.cgi?id=968405#c63 --- Comment #63 from Dr. Werner Fink <werner@suse.com> --- (In reply to Dr. Werner Fink from comment #62) Now there are two options for the servcie macros ... -f for force and -n for never ... beside the default. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=968405 http://bugzilla.suse.com/show_bug.cgi?id=968405#c64 Egbert Eich <eich@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |needinfo?(mls@suse.com) --- Comment #64 from Egbert Eich <eich@suse.com> --- The code: %if "%{stop_on_remove}"=="default" \ test "$DISABLE_STOP_ON_REMOVAL" = yes -o \ "$DISABLE_STOP_ON_REMOVAL" = 1 && exit 0 \ test -f /etc/sysconfig/services && . /etc/sysconfig/services \ test "$DISABLE_STOP_ON_REMOVAL" = yes -o \ "$DISABLE_STOP_ON_REMOVAL" = 1 && exit 0 \ %endif implies, that in 'default' mode, we want to honour $DISABLE_STOP_ON_REMOVAL not only set in /etc/sysconfig/services but coming from other sources (spec-file, global environment) as well. Do we want this - or do we want two separate modes ('legacy' and 'default')? Ie: 'legacy' - (no option flag) with the described behaviour and 'default' - (option flag -d) where we ignore $DISABLE_STOP_ON_REMOVAL from any other sources than /etc/sysconfig/services In the light of comments #38, #40 and #41 I'd like to get Michael's opinion. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=968405 http://bugzilla.suse.com/show_bug.cgi?id=968405#c65 Michael Schröder <mls@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(mls@suse.com) | --- Comment #65 from Michael Schröder <mls@suse.com> --- I think having legacy and default makes things too complicated for the packagers. I'm ok with Werner's proposal. Two nitpicks: 1) I guess it should be %stop_on_removal for consistency 2) Please use %define instead of %global so that multiple subpacks can have different settings (i.e. the macro reverts to the old value after expansion). Cheers, Michael. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=968405 http://bugzilla.suse.com/show_bug.cgi?id=968405#c66 --- Comment #66 from Dr. Werner Fink <werner@suse.com> --- Created attachment 667474 --> http://bugzilla.suse.com/attachment.cgi?id=667474&action=edit Using lua interpreter to avoid define or global command This one does produce bash code for the default (no option): /usr/bin/systemctl --no-reload disable display-manager.service || : ( test "$YAST_IS_RUNNING" = instsys && exit 0 test -f /etc/sysconfig/services -a -z "$DISABLE_STOP_ON_REMOVAL" && . /etc/sysconfig/services test "$DISABLE_STOP_ON_REMOVAL" = yes -o "$DISABLE_STOP_ON_REMOVAL" = 1 && exit 0 /usr/bin/systemctl try-restart display-manager.service || : ) for the force option -f: ( test "$YAST_IS_RUNNING" = instsys && exit 0 /usr/bin/systemctl try-restart display-manager.service || : ) and for the never option -n simply nothing. Note that I've used a check if the variable DISABLE_STOP_ON_REMOVAL (or DISABLE_RESTART_ON_UPDATE) is already set that is that the file /etc/sysconfig/services is only sourced if the variable is not set. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=968405 Egbert Eich <eich@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(eich@suse.com) | -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=968405 Egbert Eich <eich@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |968172 -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=968405 Egbert Eich <eich@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |968631 -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=968405 http://bugzilla.suse.com/show_bug.cgi?id=968405#c71 Dr. Werner Fink <werner@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #667474|0 |1 is obsolete| | --- Comment #71 from Dr. Werner Fink <werner@suse.com> --- Created attachment 667586 --> http://bugzilla.suse.com/attachment.cgi?id=667586&action=edit Using options only, no lua (In reply to Egbert Eich) OK, OK ... it seems that within %{ ... } the line ending has not to be escaped. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=968405 http://bugzilla.suse.com/show_bug.cgi?id=968405#c72 Dr. Werner Fink <werner@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |needinfo?(mls@suse.com) --- Comment #72 from Dr. Werner Fink <werner@suse.com> --- (In reply to Dr. Werner Fink from comment #71) The only question I've: does rpm on Leap42.1 and SLES12 SP0, SP1, and also SP2 do this in the same way that is no escaped newline is required witin %{ ... }? Only problem I see is that rpm includes the options into the %{*} of the expanded macro ( test "$YAST_IS_RUNNING" = instsys && exit 0 /usr/bin/systemctl try-restart -f display-manager.service ) ... how can I avoid this? -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=968405 http://bugzilla.suse.com/show_bug.cgi?id=968405#c73 Dr. Werner Fink <werner@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution|--- |FIXED --- Comment #73 from Dr. Werner Fink <werner@suse.com> --- (In reply to Dr. Werner Fink from comment #72) ... no expansion of a macro with options but macro expansion with options works. SR#365189 -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=968405 http://bugzilla.suse.com/show_bug.cgi?id=968405#c75 Michael Schröder <mls@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(mls@suse.com) | --- Comment #75 from Michael Schröder <mls@suse.com> --- #72: processed options are not included in %{*} I would simply do it like this (untested): %_stop_check_systemctl(fn) \ %{-n:exit 0} \ %{!-n:\ test "$YAST_IS_RUNNING" = instsys && exit 0 \ %{!-f:\ test -f /etc/sysconfig/services && . /etc/sysconfig/services \ test "$DISABLE_STOP_ON_REMOVAL" = yes -o \ "$DISABLE_STOP_ON_REMOVAL" = 1 && exit \ } \ } \ /usr/bin/systemctl stop %nil No extra macros, no %if statement, just option processing. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=968405 http://bugzilla.suse.com/show_bug.cgi?id=968405#c78 --- Comment #78 from Andrei Borzenkov <arvidjaar@gmail.com> --- I updated TW to current snapshot and was kicked out of GUI. I'm using XFCE installation pattern with lightdm; I do not see anything related to service restart in lightdm, but I see that xdm was updated (1.1.11-17.1 -> 1.1.11-18.1). Is it (loss of GUI session) expected in this case? Even if this is fallout of %postuninstall of previous version - I'm using lightdm as display manager, why updating of *xdm* restarts it? -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=968405 http://bugzilla.suse.com/show_bug.cgi?id=968405#c79 --- Comment #79 from Egbert Eich <eich@suse.com> --- (In reply to Andrei Borzenkov from comment #78)
I updated TW to current snapshot and was kicked out of GUI. I'm using XFCE installation pattern with lightdm; I do not see anything related to service restart in lightdm, but I see that xdm was updated (1.1.11-17.1 -> 1.1.11-18.1). Is it (loss of GUI session) expected in this case?
Even if this is fallout of %postuninstall of previous version - I'm using lightdm as display manager, why updating of *xdm* restarts it?
Andrei, Since the faulty code is in the uninstall scriptlet of the *old* package this will happen until a *fixed* package is updated ie gets uninstalled. The uninstall scriptlets of a package(-version) are stored in the rpm database until this package(-version) is removed completely. So even though the issue is fixed, you will suffer from it once more. Only the next time around, when this package is updated *again* you should be fine. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=968405 http://bugzilla.suse.com/show_bug.cgi?id=968405#c85 Lars Marowsky-Bree <lmb@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Priority|P5 - None |P3 - Medium Status|RESOLVED |REOPENED CC| |lmb@suse.com Resolution|FIXED |--- --- Comment #85 from Lars Marowsky-Bree <lmb@suse.com> --- Hey, I don't mean to be a killjoy, and I may have missed something in the rather long discussion of this bug - but with tumbleweed, updating xdm *still* terminates the user's session. May 02 09:33:35 hermes [RPM][1966]: install xdm-1.1.11-19.2.x86_64: success May 02 09:33:35 hermes systemd[1]: Reloading. May 02 09:33:35 hermes systemd[1]: nss-lookup.target: Dependency Before=nss-lookup.target dropped May 02 09:33:35 hermes systemd[1]: Started CUPS Scheduler. May 02 09:33:35 hermes [RPM][1966]: erase xdm-1.1.11-19.1.x86_64: success May 02 09:33:35 hermes systemd[1]: Reloading. May 02 09:33:35 hermes systemd[1]: nss-lookup.target: Dependency Before=nss-lookup.target dropped May 02 09:33:35 hermes systemd[1]: Started CUPS Scheduler. May 02 09:33:35 hermes systemd[1]: Stopping X Display Manager... May 02 09:33:35 hermes org.gtk.vfs.Daemon[2740]: A connection to the bus can't be made May 02 09:33:35 hermes su[2902]: pam_unix(su-l:session): session closed for user root May 02 09:33:35 hermes kdm[2689]: :0[2689]: pam_unix(xdm:session): session closed for user lmb ... May 02 09:33:37 hermes systemd[1]: Stopped X Display Manager. May 02 09:33:37 hermes systemd[1]: Starting X Display Manager... This is rather consistently annoying ;-) Is there any chance to avoid this without modifying /etc/sysconfig/services globally? -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=968405 http://bugzilla.suse.com/show_bug.cgi?id=968405#c86 Stefan Dirsch <sndirsch@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |needinfo?(lmb@suse.com) --- Comment #86 from Stefan Dirsch <sndirsch@suse.com> --- Lars, did you see comment #79, i.e. can you do us a favor and re-update the xdm package once more (with --force or --oldpackage or whatever will be required) in a running session in order to verify the issue is fixed? Thanks! -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=968405 http://bugzilla.suse.com/show_bug.cgi?id=968405#c87 --- Comment #87 from Lars Marowsky-Bree <lmb@suse.com> --- OK, so "zypper in --force xdm" does not reproduce this, but I had already updated several times since the fixes mentioned up to comment 84 were added. So I'd have thought I've already got the package update. I tried downloading the package with -d and then used rpm -U --force directly. But that doesn't trigger the "erase" transaction either, since the new package version and the installed one are identical. I'll try installing xdm-1.1.11-19.1 and then re-upgrading to xdm-1.1.11-19.2 again. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=968405 http://bugzilla.suse.com/show_bug.cgi?id=968405#c88 Lars Marowsky-Bree <lmb@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution|--- |FIXED Flags|needinfo?(lmb@suse.com) | --- Comment #88 from Lars Marowsky-Bree <lmb@suse.com> --- OK, so my session is still here, seems to have worked ;-) Thanks. Sorry for the noise, just somewhat surprised it took so long for the fix to hit tumbleweed. Let's hope for the best. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=968405 Swamp Workflow Management <swamp@suse.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Whiteboard|ibs:running:1423:low |ibs:running:1423:low |obs:running:5519:low | -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=968405 Swamp Workflow Management <swamp@suse.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Whiteboard|ibs:running:1423:low |ibs:running:3128:low -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=968405 http://bugzilla.suse.com/show_bug.cgi?id=968405#c93 --- Comment #93 from Bernhard Wiedemann <bwiedemann@suse.com> --- This is an autogenerated message for OBS integration: This bug (968405) was mentioned in https://build.opensuse.org/request/show/544180 Factory / systemd-rpm-macros -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=968405 http://bugzilla.suse.com/show_bug.cgi?id=968405#c94 --- Comment #94 from Bernhard Wiedemann <bwiedemann@suse.com> --- This is an autogenerated message for OBS integration: This bug (968405) was mentioned in https://build.opensuse.org/request/show/547058 Factory / systemd-rpm-macros -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=968405 http://bugzilla.suse.com/show_bug.cgi?id=968405#c95 --- Comment #95 from Swamp Workflow Management <swamp@suse.de> --- This is an autogenerated message for OBS integration: This bug (968405) was mentioned in https://build.opensuse.org/request/show/576778 Factory / systemd-rpm-macros -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=968405 http://bugzilla.suse.com/show_bug.cgi?id=968405#c96 --- Comment #96 from Swamp Workflow Management <swamp@suse.de> --- This is an autogenerated message for OBS integration: This bug (968405) was mentioned in https://build.opensuse.org/request/show/611238 Factory / systemd-rpm-macros -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=968405 Maintenance Robot <maint-coord+maintenance_robot@suse.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Whiteboard|ibs:running:3128:low | -- 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