Description of problem: mga-applet runs but fails to determine whether system is up to date. As a result there is no notification when updates are available. Version-Release number of selected component (if applicable): How reproducible: Watch the system journal and note that mga-applet never follows up with an analysis of the downloaded repository information after having run urpmi.update. Steps to Reproduce: 1. 2. 3. Reproducible: Steps to Reproduce:
I removed mgaonline with rpm -e. I then reinstalled mgaonline and checked for the file â/etc/cron.daily/mgaupdate. It had not been created and rpm -V mgaonline does not detect that it is missing. I am no longer even seeing mga-applet run when I check the system journal. And I am not getting any notifications when updates are available.
(In reply to George Mitchell from comment #1) > I removed mgaonline with rpm -e. I then reinstalled mgaonline and checked > for the file â/etc/cron.daily/mgaupdate. It had not been created and rpm -V > mgaonline does not detect that it is missing. I am no longer even seeing > mga-applet run when I check the system journal. And I am not getting any > notifications when updates are available. OK ... this one should not exist because it is a ghost file. But that still does not address the problem that the update notification system has stopped working.
does it work if you launch manually mgaapplet ? (iirc it doesn't work in cauldron as the applet doesn't search in */release but I really not sure)
Version: 3 => CauldronAssignee: bugsquad => thierry.vignaud
At this point mgaapplet is running. In fact there are now two instances of it running. Not sure why that is. But it is not checking for updates. Up to a few days ago it was downloading the status files, but doing nothing with them. Normally it will indicate on the journal either that there are updates available or that no updates are available and everything is current. For some reason it stopped doing that. Is there some way to make mgaapplet "verbose" and launch it manually and get some sort of output from it? I haven't found much documentation on it as to how it works and that has been a real handicap in terms of trying to troubleshoot it. - George
Now it is showing up in the journal again, but still not reporting updates available. Here is the text I am seeing in the journal: May 02 06:57:52 localhost.localdomain systemd[1]: Started Stop Read-Ahead Data Collection. May 02 06:57:55 localhost.localdomain mgaapplet[2669]: running: ionice -p 2669 -n7 May 02 07:01:01 localhost.localdomain crond[2903]: pam_tcb(crond:session): Session opened for root by root(uid=0) May 02 07:01:01 localhost.localdomain CROND[2904]: (root) CMD (nice -n 19 run-parts --report /etc/cron.hourly) May 02 07:01:01 localhost.localdomain anacron[2910]: Anacron started on 2013-05-02 May 02 07:01:01 localhost.localdomain anacron[2910]: Will run job `daily-backup' in 3 min. May 02 07:01:01 localhost.localdomain anacron[2910]: Will run job `cron.daily' in 6 min. May 02 07:01:01 localhost.localdomain anacron[2910]: Will run job `daily-scrub' in 61 min. May 02 07:01:01 localhost.localdomain anacron[2910]: Jobs will be executed sequentially May 02 07:01:02 localhost.localdomain CROND[2903]: pam_tcb(crond:session): Session closed for root May 02 07:02:55 localhost.localdomain mgaapplet[2669]: Computing new updates... May 02 07:02:55 localhost.localdomain mgaapplet[2987]: running: urpmi.update -a May 02 07:02:55 localhost.localdomain userhelper[2995]: running '/usr/sbin/urpmi.update -a' with root privileges on behalf of 'ghmitch' May 02 07:03:06 localhost.localdomain mgaapplet[2987]: updating inactive backport media Core Backports (distrib7), Core Backports Testing (d May 02 07:03:06 localhost.localdomain mgaapplet[2987]: running: urpmi.update Core Backports (distrib7) May 02 07:03:06 localhost.localdomain userhelper[3021]: running '/usr/sbin/urpmi.update Core Backports (distrib7)' with root privileges on b May 02 07:03:07 localhost.localdomain mgaapplet[2987]: running: urpmi.update Core Backports Testing (distrib9) May 02 07:03:07 localhost.localdomain userhelper[3034]: running '/usr/sbin/urpmi.update Core Backports Testing (distrib9)' with root privile May 02 07:03:08 localhost.localdomain mgaapplet[2987]: running: urpmi.update Nonfree Backports (distrib17) May 02 07:03:08 localhost.localdomain userhelper[3046]: running '/usr/sbin/urpmi.update Nonfree Backports (distrib17)' with root privileges May 02 07:03:09 localhost.localdomain mgaapplet[2987]: running: urpmi.update Nonfree Backports Testing (distrib19) May 02 07:03:09 localhost.localdomain userhelper[3057]: running '/usr/sbin/urpmi.update Nonfree Backports Testing (distrib19)' with root pri May 02 07:03:10 localhost.localdomain mgaapplet[2987]: running: urpmi.update Tainted Backports (distrib27) May 02 07:03:10 localhost.localdomain userhelper[3069]: running '/usr/sbin/urpmi.update Tainted Backports (distrib27)' with root privileges May 02 07:03:10 localhost.localdomain mgaapplet[2987]: running: urpmi.update Tainted Backports Testing (distrib29) May 02 07:03:10 localhost.localdomain userhelper[3080]: running '/usr/sbin/urpmi.update Tainted Backports Testing (distrib29)' with root pri May 02 07:04:01 localhost.localdomain anacron[2910]: Job `daily-backup' started May 02 07:04:03 localhost.localdomain kernel: device label BACKUP devid 1 transid 2148 /dev/sdi May 02 07:04:03 localhost.localdomain kernel: btrfs: disk space caching is enabled And that is it. That is all I am seeing. In this case there WERE updates available at the time this ran. - George
mgaapplet runs fine when run as root, but fails when run as ordinary user: [ghmitch@localhost ~]$ mgaapplet getting exclusive lock on urpmi unlocking urpmi database medium "Core Release (distrib1)" is up-to-date medium "Core Updates (distrib3)" is up-to-date medium "Nonfree Release (distrib11)" is up-to-date medium "Nonfree Updates (distrib13)" is up-to-date medium "Tainted Release (distrib21)" is up-to-date medium "Tainted Updates (distrib23)" is up-to-date medium "Core Backports (distrib7)" is up-to-date medium "Core Backports Testing (distrib9)" is up-to-date medium "Nonfree Backports (distrib17)" is up-to-date medium "Nonfree Backports Testing (distrib19)" is up-to-date medium "Tainted Backports (distrib27)" is up-to-date medium "Tainted Backports Testing (distrib29)" is up-to-date using mirror ftp://mirrors.kernel.org/mageia/distrib/cauldron/i586 examining synthesis file [/var/lib/urpmi/Core Release (distrib1)/synthesis.hdlist.cz] examining synthesis file [/var/lib/urpmi/Core Updates (distrib3)/synthesis.hdlist.cz] examining synthesis file [/var/lib/urpmi/Nonfree Release (distrib11)/synthesis.hdlist.cz] examining synthesis file [/var/lib/urpmi/Nonfree Updates (distrib13)/synthesis.hdlist.cz] examining synthesis file [/var/lib/urpmi/Tainted Release (distrib21)/synthesis.hdlist.cz] examining synthesis file [/var/lib/urpmi/Tainted Updates (distrib23)/synthesis.hdlist.cz] error: cannot open Packages index using db5 - Permission denied (13) error: cannot open Packages database in /var/lib/rpm Fontconfig warning: "/etc/fonts/conf.d/50-user.conf", line 9: reading configurations from ~/.fonts.conf is deprecated. [xcb] Unknown sequence number while processing queue [xcb] Most likely this is a multi-threaded client and XInitThreads has not been called [xcb] Aborting, sorry about that. perl: xcb_io.c:273: poll_for_event: Assertion `!xcb_xlib_threads_sequence_lost' failed. Aborted This *may* be related to the fact that I have been removing world writable permissions scattered all over in response to msec warnings that have been pouring out. I have also been looking at other security issues. According to Red Hat's sectool, /var/lib/rpm should not be accessible to the "world". And addressing that issue killed mgaapplet. So I shall mark this bug resolved and open another one regarding the security issue. It DOES seem rather dumb to leave the package databases wide open to anyone who might wander in.
Status: NEW => RESOLVEDResolution: (none) => FIXED