Bug 11478

First of all, you didn't need to kill it.  Unless mgaapplet is in the middle of updating the media metadata and checking for updates, you can run urpmi while it's still running.  The issue is that mgaapplet only updates the media metadata and checks for updates periodically.  urpmi --auto-update forces it to check immediately, so of course that's going to work.  This is expected behavior.

Status: NEW => RESOLVED
Resolution: (none) => INVALID

Hi, 

I think you close that bug report a bit too quickly, maybe I didn't find the good culprit, but still:

1) urpmi could not be ran because the database is used and locked by the other process, so I had to kill it to be able to use urpmi

2) it is not normal that something (what ever it is) takes more than 30min to check for updates when urpmi only takes 1min and it should not be let like that for mga4.

Status: RESOLVED => REOPENED
Resolution: INVALID => (none)

You didn't say that it had kept the database locked.  This is obviously not good.  Is this problem reproducible, or did it only happen once?

CC: (none) => thierry.vignaud

I rebooted around 20:30 (CEST) expecting such a question.

and now, at 21:50, I'm still waiting for the icon to appear in the bar and I have that:
********************

$sudo urpmi --auto-update
la base de donnée urpmi est verrouillée, le programme 17247 l'utilise (/usr/bin/perl /usr/libexec/urpmi.update Core Backports Testing (distrib49))

$ ps -eaf | grep 17247
root     17247  4395  0 21:48 ?        00:00:00 /usr/bin/perl /usr/libexec/urpmi.update Core Backports Testing (distrib49)
root     17330 17247  0 21:49 ?        00:00:00 /usr/bin/curl -q -s --location-trusted -R -f --disable-epsv --connect-timeout 60 --anyauth --stderr - -O ftp://ftp.LinuxCabal.org/pub/mirrors/Mageia/distrib/cauldron/x86_64/media/debug/nonfree/updates_testing/media_info/MD5SUM
grenoya  17334  3550  0 21:49 pts/4    00:00:00 grep --color 17247

$ ps -eaf | grep mgaa
grenoya   3792  1979  0 20:34 ?        00:00:00 /usr/bin/perl /usr/bin/mgaapplet
grenoya   4395  3792  0 20:39 ?        00:00:00 /usr/bin/perl /usr/bin/mgaapplet
grenoya  17301  3550  0 21:49 pts/4    00:00:00 grep --color mgaa

********************

I find it weird to have 2 mgaaplet launched and, even weirder, the second is launched by the first!

Tell me what other information you want.

I don't know if the 2 processes are weird, I'm not that familiar with the implementation, but it could just be that the first one forks a child process for some reason.  If you're at 21:50 and those processes started at 21:48 and 21:49, maybe not enough time has gone by yet (although even that *should* be enough time).  After waiting a while longer, do these processes ever go away?

If not, do you experience issues trying to use curl in general?  It was just updated yesterday right before the freeze, so maybe there's an issue with it.  If it works in general, try the exact curl command you see in your process list.  I just ran it on Mageia 3, and it produced no console output, but it completed in 6 seconds and downloaded an MD5SUM file to the current working directory (file size 576 bytes).

(In reply to David Walser from comment #5)
> I don't know if the 2 processes are weird, I'm not that familiar with the
> implementation, but it could just be that the first one forks a child
> process for some reason.

On my work machine (mga2) I have only 1 mgaaplet process (I know that's not representative as a lot of think can have change between mga2 and now)

>  If you're at 21:50 and those processes started at
> 21:48 and 21:49, maybe not enough time has gone by yet (although even that
> *should* be enough time).

You're not looking at the good figures: mgaapplet started with my xfce session  more than 1h before I posted (start of mgaaplet at 20:34). Usually less than 15min after starting the session, you have an icon apearring in the bar telling you if you have or not updates/ugrades available. More than one hour after the start of the session, the process checking on mirror had not finish running.

The figures you pointed are for the independent process launched by mgaapplet for each repository (I bet it's a loop, scanning each repository after another).

>  After waiting a while longer, do these processes
> ever go away?
> 
> If not, do you experience issues trying to use curl in general?  

If I'm not wrong, "urpmi --auto-update" uses curl too for retreiving the hdlists. And urpmi works well and quickly so I'd say curl is OK.

Hi,

Yesterday the auto scan of the mirror by mgaapplet took more than 1h30. After that I updated (500 or packages, happy mass rebuild!).

This morning, trying to use urpmi the message has changed:

****
sudo urpmi --auto-update
la base de donnée urpmi est verrouillée, le programme 4218 l'utilise (/usr/bin/perl /usr/libexec/urpmi.update -a)
*****

and it took less then 30min whitch is a great improvment \o/.
So something has been changedin mgaapplet, but, as I don't know if the fact that I let it finished yesterday had an impact or not, I will continue keepping an eye on the problem this week.

Hi
unfortunatly, it's not better :
yesterday mgaapplet took more than half an hour to check every thing, then I updated everything.
today it's taking more than 3 quarter!

Cauldron is not usable like that. 

@Thierry : if you whant me to do any test, please feel free to ask.

Claire, the mass rebuild is in progress, so there are a very
large number of updates, and a massive amount to download.
While annoying, this is normal for cauldron, when a mass
rebuild is in progress. It will take another day or two to
get back to normal.

CC: (none) => davidwhodgins

Dave,

you still don't get the problem: it's not about downloading the new packages, only the hdlists. That's the task mgaapplet is doing 5min (standart configuration) after the start of the session and that's the first step of "urpmi --auto-update".

For that same tasks mgaapplet takes a huge lot of time when "urpmi --auto-update" takes less than 5 min, mass rebuild or not. There is a problem in the deference of implementation. Maybe it's a problem of timeout on mirror answers, I don't know, and I'm not skilled enough to dive into the code.

But we can't expect that simple user will either kill mgaapplet to be able to install something nor wait one hour.

https://bugs.mageia.org/show_bug.cgi?id=11542 could be the cause

Yes, indeed! 
I'll wait for the other bug to be resolved before checking mgaapplet behavior again.

thanks a lot Manuel for making the link :)

I think this one was fixed (from previous discussions) but if not please reopen it!!

Status: REOPENED => RESOLVED
CC: (none) => mageia
Resolution: (none) => FIXED