Is there a reason why osascript would cease responding after a period of time ? I have an osascript call to an AppleScript which is hanging after a long time e.g. 30 minutes.
The AppleScript starts a background process which processes data and sends results to a log file.
The AppleScript monitors that process, checks the log file and shows a progress dialog with detail from the log.
The AppleScript redisplays the progress dialog every 5 seconds until the process which updates the log file ceases.
The process which updates the log file can take a long time e.g. 45 minutes. So, the AppleScript which monitors that process needs to keep running all that time. However, the osascript process ceases to respond after around 30 minutes. The dialog stays visible but the mouse pointer is a spinning rainbow of death. It then is necessary to kill the osascript process.
Although the osascript has died, the process which updates the log file continues and concludes properly, when it has finished processing data.
Is there a reason why an osascript would just stop responding ?
(1) This call, starts the background script which hangs after 30 minutes:
set my_params to quoted form of …[44 separate parameters] set myMonitorScriptAsString to quoted form of ((POSIX path of path_to_applet) & “Contents/Resources/Script Libraries/Monitor.scptd”) do shell script “osascript -s s " & myMonitorScriptAsString & " " & my_params & " " & " > /dev/null 2> /dev/null &”
(2) The myMonitorScriptAsString script starts another background (Python) process which updates a log file while running:
(3) The myMonitorScriptAsString script monitors the Python process using “python_process_pid”. It collects the most recent data from the log file and displays a dialog. The whole monitoring process and dialog are inside a repeat loop – the dialog has a “giving up after 5” parameter. Thus the repeat loop is looped every 5 seconds. Exiting the repeat loop is done by this:
try
– does the PID exist? do shell script "ps -p " & python_process_pid onerror exitrepeat endtry
So, when the python_process_pid can’t be found, showing its process is no longer running, the “myMonitorScriptAsString” script exits the repeat loop and stops.
However, the python_process_pid can take 30-40 minutes to complete. For some reason the “myMonitorScriptAsString” script hangs before then, usually at around the 30 minute mark. during that period, the myMonitorScriptAsString is checking the log file and reporting what it finds in a dialog for the user. There are no issues when the Python process runs for a shorter time e.g. 5 minutes or 20 minutes.
I would like any help available on why a script running a repeat loop would hang after a long period of time.
Still hard to tell without actual code, though. Can you build a minimal example that demonstrates the issue? Does the monitor script do something like use NSTask or a Cocoa run loop?
Just as a ballpark figure, how many times is the script generating a dialog that exits after 5 seconds?
Also since the script is not running in a GUI app, but as a command line osascript, using dialogs is fraught with problems. It is best to have the script send the dialog to application “system events” like so…
tell application "system events"
display dialog "Script progress text here" giving up after 5
end tell
I might be able to build a model but, I’m under pressure to finish a new release as soon as possible. The relevant code in the applet is 4,900 lines (including comments). Most of that is code which forms the osascript call excerpted above with some unconnected utilities. The “Monitor” script which starts and monitors the Python process is about 600 lines.
I don’t know what a “Cocoa run loop” is. All the repeat loops are standard AppleScript “repeat/end repeat” structures. Timing is controlled by the “giving up after” in the dialog. After the dialog closes, code checks whether the user has clicked a button and handles that accordingly which usually involves ending the repeat loop. If the user does not lick a button, the repeat loop continues monitoring the log until the Python process ceases to exist.
The monitor script will show the dialog maybe 360 times in 30 minutes. More usually, however, it only runs for a few minutes and so redisplays 100 times or less.
The dialog is created with a copy of Dialog Toolkit Plus to which I have made minimal customisations.
I am very fortunate that AppleScript is so quick. There is usually barely a perceptual blink between the dialog closing and the updated dialog displaying.
I’m just trying to figure out exactly what you are doing, because it sounds a bit like a full buffer or queue somewhere.
The run loop is what periodically processes various events, such as the UI, so one cause for the beach ball of death is by continual repeat statements, which jams up the event queue by not giving the system any time to handle events. This is a routine cause of things like a progress indicator not updating, for example.
Many thanks. That could well be the issue and would explain why there’s no hang until after a long time and a lot of repeat loop iterations. I’ve also wondered if this was an AppleScript “resources” issue. But, that usually causes a crash and nasty error message to the user.
In case you are keen to look at the code, I’ve uploaded a set of exported text files containing the AppleScript code. They are available here:
The scripts relevant to the issue are: main.applescript and monitor.applescript. All the script files except main are stored as Script Libraries in the applet’s bundle (a change in the next version).
I think I’ve found a clue to what’s causing the hangs. I’ve just done two tests. The first hanged at 5.8 minutes while the second did not hang and finished normally after 37:46.
I think the only difference between the two tests was that for the second, I watched the whole time. Thus, I did not let the Mac go into sleep or turn off the monitor.
As mentioned, the “monitor” dialog is shown using Dialog Toolkit Plus. It is modal and can’t be hidden. Perhaps the script hangs when it can’t show the dialog (because the Mac is some kind of sleep). But, I had my Mac set to “Prevent automatic sleeping…” and “Turn display off when inactive” set to 15 minutes. So perhaps this doesn’t explain the crash after less than 6 minutes. Nonetheless, I’ll work on that idea in case there’s something in it.