Dialog says app is not responding when it was responding

Please tell me where I should post this problem. I’m posting here because I do not know which forum is my best bet. I’m running a fully up-to-date version of Zorin OS Ultimate 15.3.

I have developed some Python apps. I had one running this moring named Foci. It seems to be working perfectly. It was waiting for me to start clicking on entries of a Gtk treeview. While I was reading something on the internet using Chrome, a dialog suddenly appeared saying that foci.py was not responding. This is the first time I have encountered this except for when I have been in vs code. I was dutifully installing all updates as soon as they arrived. This problem began in vs code a couple of weeks ago after months of not ever seeing it. It happened outside of vs code for the first time today.

The behavior of this dialog was the same as in vs code. That is, I did not have vs code running. I was running the app from a terminal (>python3 foci.py). The dialog does not identify its source, but it has two buttons: Force Quit and Wait. If I click Wait, the dialog closes, but immediately reopens. If I click Wait again, the button goes white and the app and dialog both go non-responsive. I can get them to be responsive again by typing alt-F2. When the command dialog opens I do not type anything … I just click close. The Wait button returns to black, but clicking again leads to the same, exact sequence of events as the first time. If, instead, I click Force Quite, it does force the app to quit if I’m not in vs code. However, in vs code the dialog and code both freeze.

I think the dialog must be coming from the OS, but it is baffling. Foci.py was responding perfectly. This is serious for me. I need to be using daily the 3 Python apps that I’ve spent the past several months or so developing.

Thanks for any help or advice.

Are you running any scripts from terminal?
What version of python do you have installed?

Yes, I am always running them from terminal. I’ve been running them for several weeks with this happening today for the first time (except for in vs code break-point mode).
From terminal I get 3.6.9 for python3, which I always use.

‘3.6.9 (default, Oct 8 2020, 12:12:24) \n[GCC 8.4.0]’

This same version is reported from a script running in vs code:

3.6.9 (default, Oct 8 2020, 12:12:24)
[GCC 8.4.0]

Do you have a


file on your system?
If python was updated recently, it is possible that the versions no longer match.
If that file is present, check that the first line reads


The line does not say 3.6.9. It says:

That actually should be good… But for FUN you might try making it say just python to revert it to python 2 as that may actually work.
Other than that- we will need to hit the Searches because that is the only idea I have.

I may have panicked. This was such a problem for me in vs code that I may have over-reacted when it occurred today running from terminal. The same script, foci, has been running in terminal for the past 2 hours or so and it has not happened again. If it does, I will try your suggestion. For now, I’m just happy to get on with things. As always, thanks for your quick response. I did a lot of searching before posting this and was surprised to find nothing.

1 Like

This problem is still happening. I must find a solution. I am still running the scripts from a terminal because I do not yet know another way to run them. I need some of my scripts to run continuously… such as my schedule manager. In fact, I intend to set the schedule app to start with login. I will do the searches again to see if others have solutions. Maybe something has been added since I last searched. It’s interesting that only my python scripts are having this issue … and they even have it sometimes when I am running them inside of vs code.

Not necessarily a solution, but an effective workaround may be to change the timeout on what prompts the message from 5 seconds to 60 seconds. You may be able to do this with a gsettings command

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

reboot and test…

If that does not work, the libmutter file may need to be upp’ed to a newer version. I am not sure the exact steps to do that but can search it easily and provide that if you need. (I am pretty sure that the current Zorin 15 version should be new enough).

gsettings --version = 2.58.1
need version 3.35.92
sudo apt-get install gsettings – gsettings not found
libmutter-6-0_3.36.7+git20201123- found on UbuntuUpdates

Ok. I tried this, but it says that there is no such key. Research indicates that gsettings version 3.35.92 is needed for this setting. I have version 2.58.1. I see that the latest version of libmutter is 6-0_3.36.7. I’m afraid to update either one without knowing for sure that I won’t screw my system up. I do have timeshift backups.

Should I download the libmutter pkg from UbuntuUpdates?

I had not realized that the access to that setting is so recent a change…
Looking around the web, I found this write up (need to scroll way down). I cannot vouch for how well it works as I have not tested it

So, Yes- Timeshift!
His instructions include:

One way to achieve this is to change how long time a window is allowed to be “not responding” before the dialog is shown. The code that handles this is in the libmutter-4-0 library, where the time is hard-coded to 5 seconds. Beware that the following is kind of a hack, not very elegant, but it does work. (And I had some fun doing it!)

sudo apt-get source libmutter-4-0

Before entering the following, compare the name of the version you actually get against this command:

cd mutter-3.32.2+git20190711

Thanks, Aravisian. I will try this a bit later when I have time. It might take me awhile to get it right given that the last time I coded in C was 1992. Meanwhile, I will put a clock on the apps main window … preferably the titlebar. I’m hoping that the constant update of the seconds display will tell the mutter lib routine that the app isn’t stalled.

A Very Clever Idea. Please update how that works out.