| Summary: | mgaapplet-update-checker keeps the urpmi database locked even if network is hanging | ||
|---|---|---|---|
| Product: | Mageia | Reporter: | Elmar Stellnberger <estellnb> |
| Component: | RPM Packages | Assignee: | Mageia tools maintainers <mageiatools> |
| Status: | NEW --- | QA Contact: | |
| Severity: | normal | ||
| Priority: | Normal | ||
| Version: | Cauldron | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Source RPM: | mgaonline-3.31-3.mga9.src.rpm | CVE: | |
| Status comment: | |||
|
Elmar Stellnberger
2023-05-18 11:05:32 CEST
Summary:
mgaapplet-updatechecker keeps the urpmi database locked even if network is hanging =>
mgaapplet-update-checker keeps the urpmi database locked even if network is hanging Yes, it is annoying when the RPM database remains locked when you want to do something 'package'. I find that it usually becomes free before too long; but if as you say it gets stuck because a network is hung, this is worth addressing. Assigning to the 'tools' maintainers. Assignee:
bugsquad =>
mageiatools |
Yesterday on the beach when I have tried out connecting to the Wifi in Altanea/BaiaBlu, the internet connection worked well, initially. When I then searched for some software I got the following message: > urpmf nwm| grep applet Die urpmi-Datenbank ist gesperrt, der Prozess 6325 nutzt sie bereits (/usr/bin/perl /usr/libexec/urpmi.update Nonfree Backports) "The urpmi database is locked, process 6325 is already using it" Mgaapplet kept the urpmi database locked for somewhat much longer than a minute, which started to annoy. Killing urpmi.update did not help since it was quickly started again. Using 'pstree -p' I soon got to the culprit which was mgaapplet from the mgaonline package. Killing both programs succeeded and I could quickly execute urpmf. However when I wanted to install networkmanager-applet a few seconds later the Wifi started to hang again. This request is about a senseful timeout for mgaapplet, if it detects to be online but does not succeed to connect to the server. It should free its lock on the rpm database and go to sleep for a while whenever it can´t connect in time. Otherwise you can not even invoke an 'rpm -ivh mypkg', perhaps not even an 'rpm -qa'.