Bug 963318 - PackageKit is restarted during update interrupting session
Summary: PackageKit is restarted during update interrupting session
Status: RESOLVED DUPLICATE of bug 968405
Alias: None
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: GNOME (show other bugs)
Version: Current
Hardware: Other Other
: P5 - None : Critical (vote)
Target Milestone: ---
Assignee: E-mail List
QA Contact: E-mail List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-01-23 07:29 UTC by Andrei Borzenkov
Modified: 2016-02-26 15:27 UTC (History)
2 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Andrei Borzenkov 2016-01-23 07:29:52 UTC
TW installed with XFCE pattern. Logged in, got notification about pending updates, started installation using update applet. Somewhere in the middle it stuck. Checking what happened it seems that PackageKit update restarted daemon which interrupted current session. Closed current (hung) window, after several seconds got again notification and remaining pending updates were installed. But now I have two versions of PackageKit installed:

linux-ffk5:~/PackageKit # rpm -qa PackageKit\*
PackageKit-1.0.11-1.1.x86_64
PackageKit-1.0.11-1.2.x86_64

● packagekit.service - PackageKit Daemon
   Loaded: loaded (/usr/lib/systemd/system/packagekit.service; static; vendor preset: disabled)
   Active: inactive (dead)

Jan 23 09:59:35 linux-ffk5 [RPM][22396]: Transaction ID 56a324d7 started
Jan 23 09:59:37 linux-ffk5 [RPM][22396]: install PackageKit-1.0.11-1.2.x86_64: success
Jan 23 09:59:37 linux-ffk5 systemd[1]: Stopping PackageKit Daemon...
Jan 23 09:59:37 linux-ffk5 [RPM][22396]: scriptlet %postun(PackageKit-1.0.11-1.1.x86_64) failure: 2
Jan 23 09:59:38 linux-ffk5 systemd[1]: Stopped PackageKit Daemon.
Jan 23 09:59:38 linux-ffk5 systemd[1]: Starting PackageKit Daemon...
Jan 23 09:59:38 linux-ffk5 PackageKit[22456]: daemon start
Jan 23 09:59:38 linux-ffk5 systemd[1]: Started PackageKit Daemon.
Jan 23 09:59:58 linux-ffk5 PackageKit[22456]: daemon quit
Jan 23 09:59:58 linux-ffk5 packagekitd[22456]: (packagekitd:22456): GLib-CRITICAL **: Source ID 10 was not found when attempting to remove it

Not sure what additional information is required or can be collected at this point.
Comment 1 Atri Bhattacharya 2016-01-23 15:05:04 UTC
And if you were updating via the offline-updates method (as I was), the same PK update simply hung the system in the non-gui installing-updates mode with the only way out being switching to a different VT and effecting a manual "shutdown". The reason I believe this is the same bug is because I got the same journal logs, notably with the message "scriptlet %postun(PackageKit-1.0.11-1.1.x86_64) failure: 2".* After effecting the manual shutdown and then booting in as usually, gnome-software shows "Updates failed to install". The only way to successfully install the update stack (20160120 I believe it was) was to use zypper. In the latter case, the update went swimmingly. Should be critical in my opinion, esp. for those using GNOME doing the update via the recommended way of offline installs.

* Jan 21 13:53:12 linux-b3rv [RPM][16099]: scriptlet %postun(PackageKit-1.0.11-1.1.x86_64) failure: 2
Comment 2 Dominique Leuenberger 2016-01-26 15:06:20 UTC
(In reply to Atri Bhattacharya from comment #1)

> * Jan 21 13:53:12 linux-b3rv [RPM][16099]: scriptlet
> %postun(PackageKit-1.0.11-1.1.x86_64) failure: 2

grmbl... postun does not have ANY command that could potentially fail:

postuninstall scriptlet (using /bin/sh):

if [ $1 -eq 0 ]; then                                          
  if test -x /usr/bin/update-mime-database; then             
    /usr/bin/update-mime-database "/usr/share/mime" || true 
  fi                                                           
fi
# Do not restart PackageKit on upgrade - it kills the transaction
export DISABLE_RESTART_ON_UPDATE=yes

test -n "$FIRST_ARG" || FIRST_ARG="$1"							
if [ "$FIRST_ARG" -ge 1 ]; then								
	# Package upgrade, not uninstall						
	if [ -x /usr/bin/systemctl ]; then						
		/usr/bin/systemctl daemon-reload || :					
		( 
	test -f /etc/sysconfig/services && . /etc/sysconfig/services			
	test "$YAST_IS_RUNNING" = instsys       && exit 0				
	test "$DISABLE_RESTART_ON_UPDATE" = yes && exit 0	

^^^ Latest here, the script will be ended in an upgrade case anyway... so everything below won't ever run

			
	/usr/bin/systemctl try-restart  packagekit.service || : )				
	fi										
else # package uninstall								
	for service in packagekit.service ; do							
		sysv_service="${service%.*}"						
		rm -f "/var/lib/systemd/migrated/$sysv_service" || :			
	done										
	if [ -x /usr/bin/systemctl ]; then						
		/usr/bin/systemctl daemon-reload || :					
	fi										
fi											


test -n "$FIRST_ARG" || FIRST_ARG="$1"							
if [ "$FIRST_ARG" -ge 1 ]; then								
	# Package upgrade, not uninstall						
	if [ -x /usr/bin/systemctl ]; then						
		/usr/bin/systemctl daemon-reload || :					
		( 
	test -f /etc/sysconfig/services && . /etc/sysconfig/services			
	test "$YAST_IS_RUNNING" = instsys       && exit 0				
	test "$DISABLE_RESTART_ON_UPDATE" = yes && exit 0				
	/usr/bin/systemctl try-restart  packagekit-offline-update.service || : )				
	fi										
else # package uninstall								
	for service in packagekit-offline-update.service ; do							
		sysv_service="${service%.*}"						
		rm -f "/var/lib/systemd/migrated/$sysv_service" || :			
	done										
	if [ -x /usr/bin/systemctl ]; then						
		/usr/bin/systemctl daemon-reload || :					
	fi										
fi
Comment 3 Dominique Leuenberger 2016-02-26 14:55:58 UTC
The recent resart of xdm during installation helped in uncovering the root for this issue as well:

https://build.opensuse.org/package/rdiff/openSUSE:Factory/systemd-rpm-macros?linkrev=base&rev=14

That change made the variable, exported during the script execution, no longer have any effect.
Comment 4 Dominique Leuenberger 2016-02-26 15:27:50 UTC
WEll, if the X-Team does not accept that this depends on the outcome of the other bug, then I mark is a DUP - the same root cause - the same broken systemd macros.

*** This bug has been marked as a duplicate of bug 968405 ***