Bug 31105 - "Mageia Welcome is not responding, wait or cancel" on Gnome Live ISO when 'add on-line repos' and 'update system', multiple popups:
Summary: "Mageia Welcome is not responding, wait or cancel" on Gnome Live ISO when 'ad...
Status: RESOLVED FIXED
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: Cauldron
Hardware: All Linux
Priority: release_blocker normal
Target Milestone: ---
Assignee: GNOME maintainers
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2022-11-10 20:58 CET by Ben McMonagle
Modified: 2023-03-27 06:25 CEST (History)
5 users (show)

See Also:
Source RPM:
CVE:
Status comment:


Attachments

Description Ben McMonagle 2022-11-10 20:58:01 CET
Description of problem:
after installation from:
ISO:  Mageia-9-alpha1-Live-GNOME-x86_64.iso
DATE: Sun Nov  6 07:26:05 PM CET 2022

using Mageia Welcome app, both the *add on-line repos*  and *update system* links appear to cause many popups: 
*"Mageia Welcome" is not responding*
wait or cancel.

Version-Release number of selected component (if applicable):


How reproducible:often


Steps to Reproduce:
1.install from above ISO
2.use Mageia welcome to initiate adding online repos and updating system
3.
Comment 1 Lewis Smith 2022-11-10 21:45:35 CET
Thank you for the report.
Are you the only person to report it (be testing the Gnome Live ISO)?
Do you know whether the same problem occurs with other Live ISOs, or just the Gnome one?
Cruel question: does it happen with a Gnome-only install from the Classic ISO?

All this is to try and pin down whether it is inherent in MageiaWelcome, or something to do with Gnome's strange desktop.

The problem is so easy to try, other people will be able to comment on it.
I shall try it with Gnome on this Cauldron box (ex upgraded multi-desktop M8 Classic install).

CC: (none) => lewyssmith
Summary: multiple popups: *"Mageia Welcome" is not responding* => "Mageia Welcome is not responding, wait or cancel" on Gnome Live ISO when 'add on-line repos' and 'update system', multiple popups:
Source RPM: (none) => mageiawelcome-2.16-3.mga9.src.rpm

Comment 2 Lewis Smith 2022-11-10 21:56:46 CET
Here under Gnome, not much joy.

I could not see 'add on-line media', just 'Media sources'; possibly because they were already enabled. But doing that, 'Configure software sources' popped the usual media sources dialogue OK.

As for 'update system', that worked fine, no problems. Sigh.
Comment 3 Ben McMonagle 2022-11-10 22:03:58 CET
> Thank you for the report.
> Are you the only person to report it (be testing the Gnome Live ISO)?

I do not know ;(

> Do you know whether the same problem occurs with other Live ISOs, or just
> the Gnome one?

only Gnome

> Cruel question: does it happen with a Gnome-only install from the Classic
> ISO?

will check onto a 2 system machine.

> 


during the live install (onto 11 system machine) multiple instances of "*draklive-install" is not responding* wait or cancel" ( ~104 times)

and at least one *gurpmi is not responding* while installing bootloader.

caught your addition while adding mine:

was working from memory (on work windows machine) , you are correct  : media sources
Comment 4 Ben McMonagle 2022-11-11 00:45:47 CET
install of 64 CI alpha1: Gnome

issue is apparent immediately after I attempt via Mageia Welcome *edit software sources*: configure media => *file* => *add a specific media mirror* and the *Mirror Choice* popup is displayed.

> Cruel question: does it happen with a Gnome-only install from the Classic ISO?

apparenty yes
Comment 5 Martin Whitaker 2022-11-11 23:12:59 CET
This is caused by a change in the GNOME window manager (mutter). It now regularly pings GUI applications to check they are still alive and responding to input. The Mageia tools sleep whilst waiting for a sub-program to run, so don't respond to the pings.

Note that this happens when running the various Mageia tools directly as well as via MageiaWelcome.

A workaround is to disable the check by

  gsettings set org.gnome.mutter check-alive-timeout 0

but that disables the ability to forcibly terminate applications which are genuinely not responding.

Source RPM: mageiawelcome-2.16-3.mga9.src.rpm => (none)
CC: (none) => mageia

Comment 6 Dave Hodgins 2022-11-12 00:15:19 CET
Can the default timeout be set to 10 minutes to match that the Mageia tools
currently use?

CC: (none) => davidwhodgins

Comment 7 Lewis Smith 2022-11-12 09:13:48 CET
Thank you Martin once again for an erudite explanation.
And Dave for his suggestion.
And Ben for the tedious testing.

Why did this not show in my Cauldron system ex upgraded M8? I have:
 mutter-43.1-2.mga9
Is it just a question of chance that mutter's ping normally gets answered?

(In reply to Martin Whitaker from comment #5)
> A workaround is to disable the check by
>   gsettings set org.gnome.mutter check-alive-timeout 0
> but that disables the ability to forcibly terminate applications which are
> genuinely not responding.
Does this include terminating them via a task manager application (which is what users often do to kill unresponding applications)?
 Or using Alt/F4 ?
 Or via ps + kill from a terminal?
If not, disabling the pinging looks sensible, a normal situation.

We certainly have to do something about it, setting the mutter timeout value to 0 or at least 10 secs; indeed, does it matter if it is longer for an unresponsive application?

Assigning directly to Gnome packagers, but please go on adding comments which advance the affair.

Assignee: bugsquad => gnome

Comment 8 Martin Whitaker 2022-11-12 11:06:39 CET
(In reply to Lewis Smith from comment #7)
> Why did this not show in my Cauldron system ex upgraded M8? I have:
>  mutter-43.1-2.mga9
> Is it just a question of chance that mutter's ping normally gets answered?

I could easily reproduce it using MageiaWelcome to run one of the Mageia tools - start the tool, then do nothing for the requisite length of time.

The default timeout is 5 seconds, but maybe on your upgraded system it's set to something different. Check by

  gsettings get org.gnome.mutter check-alive-timeout

The value returned is in milliseconds.

> (In reply to Martin Whitaker from comment #5)
> > A workaround is to disable the check by
> >   gsettings set org.gnome.mutter check-alive-timeout 0
> > but that disables the ability to forcibly terminate applications which are
> > genuinely not responding.
> Does this include terminating them via a task manager application (which is
> what users often do to kill unresponding applications)?
>  Or using Alt/F4 ?
>  Or via ps + kill from a terminal?
> If not, disabling the pinging looks sensible, a normal situation.

I don't know of a task manager application in GNOME. The usual way to terminate non-responding applications is to click on the window close button and wait for the timeout, and setting the timeout to 0 disables that. And Dave's suggestion of setting the timeout to 10 minutes makes it unusable too.

Alt-F4 only works when the application is not stalled, whatever the timeout is set to. kill will work regardless.

> Assigning directly to Gnome packagers, but please go on adding comments
> which advance the affair.

Unfortunately GNOME is working as intended here. The GNOME developers think a GUI application that becomes unresponsive for more than 5 seconds is a broken application. I largely agree with them. You would expect to be able to resize or minimise a window even when the application is busy doing something.
Martin Whitaker 2022-11-19 09:36:44 CET

Priority: Normal => release_blocker

Comment 9 Martin Whitaker 2022-12-03 19:14:11 CET
mageiawelcome-2.18-1.mga9 fixes the warnings about mageiawelcome not responding. And I have made some improvements to draklive-install which mostly fixes the warnings about that. I think we'll still see occasional warnings about gurpmi2 and rpmdrake when installing large packages.
Comment 10 Lewis Smith 2022-12-04 20:21:49 CET
First, thanks for your work to improve the situation.

> I think we'll still see occasional warnings about gurpmi2 and rpmdrake
> when installing large packages
Noting for ERRATA with this in mind. Can I be clear about:
- this is for Gnome desktop use, however installed ?
- applies just to MageiaWelcome, or + other known applications?
- click 'Wait' to continue.

Keywords: (none) => FOR_ERRATA9

Comment 11 Martin Whitaker 2022-12-04 22:16:45 CET
(In reply to Lewis Smith from comment #10)
> Noting for ERRATA with this in mind. Can I be clear about:
> - this is for Gnome desktop use, however installed ?

Yes.

> - applies just to MageiaWelcome, or + other known applications?

Should no longer apply to MageiaWelcome itself, as it now starts subsidiary applications without blocking until they complete. Will probably apply to drakrpm, drakdisk, drakboot, and maybe more.

> - click 'Wait' to continue.

Best not to click 'Wait', as the pop-up will be displayed again after another 5 seconds (or whatever the timeout is set to). If you just leave it, the pop-up will be automatically removed when the application starts responding again.
Comment 12 Ben McMonagle 2023-01-01 08:42:13 CET
as of 30/12/2022 beta1 .iso this is fixed

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

Morgan Leijström 2023-02-26 15:57:08 CET

Keywords: FOR_ERRATA9 => (none)
CC: (none) => fri

Comment 13 zelda thehgd 2023-03-27 06:25:01 CEST Comment hidden (spam)

CC: (none) => Zeldafarah10


Note You need to log in before you can comment on or make changes to this bug.