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.
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.
sys.version
'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:
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
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.
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:
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.
It’s very mysterious. The timeout on the app hasn’t happened now for 2 days. The app, Schedule.py, was running all day yesterday. I almost never interact with it. I want to wait until it starts happening again before I add the clock display. Otherwise, I may never know if it helped. The app timeout has been an intermittent problem all along. Meanwhile, the app itself has not changed. It starts up with login. After an initial check of the schedule, I hardly use it.
This makes me wonder if other processes are involved.
Let’s say you are counting beans; one, two, three… As long as nothing interrupts you, the process continues smoothly. But if you are mid-count, when four people burst into the room and interrupt the process, it may be less smooth. One cannot find the other shoe. Another wants a quick explanation for how a Neutron Star creates nuclear pasta. The third needs same data collated and the forth keeps asking how you are doing over and over again.
If your processor is rotating at a higher rate- Higher CPU usage, it may take it a moment to return to the schedule.py creating little gaps in its running.
This is entirely speculative, but would you be willing to examine for whether you see a higher instance if the CPU is under a heavy load?
I would be willing, but I’m just quietly coding in python using vs code. I do run timeshift and backup at times. I haven’t noticed a correlation there, but they cannot be cpu intensive. I will pay attention the next time it occurs and check the cpu utilization. This machine has an AMD Ryzen 6-core cpu running at up to 3.9GHz. I’m not at the point of using Blender yet. I have to get these Python projects completed first. It would take some heavy apps given this cpu for an appreciable delay to occur. Granted, I’m not sure what constitutes an appreciable delay with the routines in question nor what interactions you have in mind. Early versions of all 4 Python apps have been running all morning with no timeouts occurring. They all just sit there in the GTK main loop 99.9999% of the time.
So have I. Although the 4 Python apps handle different types of data for different purposes, they are actually almost identical. I copied the Schedule.py code and modified it to produce Password.py. I copied Password.py to create Foci.py. And I copied Foci.py to create MedicalManager.py. Yet, unless my memory is faulty, it is only Schedule.py that gets the timeouts. This latter app does get run for more time. That must be the reason. Still, I don’t think the other apps have ever had a timeout.
Something must have changed, but it wasn’t my Python scripts. Schedule.py, Foci.py and Password.py have all be running non-stop, 24 hours a day for over 3 days now without a single ‘not responding’ message. I guess the problem has been killed by action or actions unknown.
Sometimes, we have to live with a minor mystery. I don’t know about you, but I cannot stand not knowing something.
But if you are up and running without hair-pulling, I can live with it.