For the web sharing experts out there.
I have a few web sharing applications, most of them are simple online forms to collect the user’s data. Some of my customers have reported getting the following error in the internet browser, instead of a success page:
Panorama X Server Error: SHELL ERROR: Application isn't running.
Or the same error with PYTHON ERROR or PERL ERROR.
I was able to get the same response, just once, The problem goes away by itself. I’m kind of in the dark right now, as I don’t understand if the services are really down, or if this is a Panorama problem.
Has anyone encountered this message? Any idea on how it can be tracked. To start, I’m planning on setting a monitor in the server computer to check if these services go down during the day, but I find it difficult to believe that 3 different services would fail.
At this point I’ve done a lot with Panorama and web serving. I’ve never seen those errors. That doesn’t strike me as an error indicating that Panorama isn’t running.
My best guess is that the error relates to Panorama trying to run a shell script. I’ve had no particular issues with Python and have used it extensively, along with PHP. I have no experience at all with Perl.
Those errors can result from use of an external script. The SHELL ERROR message would come from use of the shellscript( function (or the shellscript statement). The other error messages would come from using python or perl.
Note that Panorama itself does not use any external scripts. So I sure hope you are using these scripting languages, otherwise these errors should not appear.
Hmm, I just did a google search of “Application isn’t running”. It appears likely that this is an AppleScript error. However, SHELL ERROR is definitely an error that is generated by shellscript( or shellscript. These statements do use AppleScript to run the shell script. But they don’t reference any application, but rather use AppleScript’s builtin in do shell script feature.
If you are using the shellscript( function, you might try using posixscript( instead. This runs the shell code thru a built in API, without using AppleScript.
I should note that, like Jim Cook, I have never seen these errors. But I also don’t think I’ve ever used any external scripting languages in a CGI procedure, at least not that I can recall. (But I also can’t think of any reason why it wouldn’t work.)
Yes, I am using the external scripting languages in the code involved with the error.
The problem seems to happen only on the wee hours of the day, for example this morning it failed again for a customer in Germany attempting to download software with our tool at 2 am. The CGI-POST was logged in the server, followed by the Error Message PYTHON ERROR - Application not Running.
The user attempted 6 more times before giving up.
Later, 3 more users tried a different tool around 7am, same fail result, but with the shell error. Finally, when I got to the office and checked the server logs, I noticed the errors, gave it a try, and everything worked as expected, and it will work for the rest of the day, as far as I can tell from previous days experience. This is happening daily, early morning fails fixed as soon as I check the logs.
The server computer is set to never go to sleep. To me, something is happening in the middle of the night. I’ll keep digging.
The same external code has been working properly for years in Pan 6. We finally switched to Pan X three weeks ago, and unfortunately, the failure reports from customers started.
I’ll carefully look at the code, however, it works fine almost all the time. I’ll report back any findings.
Randomly occurring errors are always the worst to track down but I don’t see that you’ve indicated how you’re calling the external scripts…
If you’re calling the shell scripts directly, you’ve obviously set Panorama to use the current versions of Python and Perl in Preferences > Advanced >Scripting Languages.
For Python, I did have to make some changes in my scripts to handle newer Python versions than were on my Pan 6 servers.
If you’re calling the scripts via AppleScript, that might be the source of the issue. In my personal experience, I’ve found that AppleScript can seem a little flaky about paths at times. If yours aren’t perfectly hardcoded, (or correct provided in a variable) it can try to access one of the script libraries in the wrong place and decide it isn’t loaded or running. Or maybe it’s finding a wrong version.
It’s easy to install multiple copies of Python too and that depends largely on the source of the installation.