WebApp Standalone just dies, with no clue

I have created four totally different webapps that stop working with no message nor error. I am at lost as to why.

Same scenario for all four apps, but running on different servers, on different networks. In fact, the servers are installed at different locations, and they are not related to each other, at all. And yet, they are experiencing the same behavior.

They just die. No error, no message, no log file, nothing. Neither on the server, nor the client side.

I swear that I have no quit command anywhere in my code, nor anything similar.

Sometimes it will be running for days, other times for minutes, or hours. And then they die (or quit).

One of these apps have only 1-2 users connected, and only during office hours. Another has 1-25 users connected.

All of them are: WebApp standalone, with NO remote database connection (I only use SQLite local database). Mac OS X (2 are running Yosemite, 2 are Maverick). Mac Mini with 16 GB of ram, with no problem of memory pressure. Their CPU usage never goes above 20%, and my app does not go above 10%. These servers do nothing else but my webapp. All are compiled with Xojo 2015 r1, and I do have MBS plugins include, but used very lightly.

When I become aware that they are dead, I just relaunch the app and everything is running fine. No files are corrupted, no sockets are stuck.

The annoying part is having to restart all the time.

Because I get no message nor error, I have no idea what is going on. How can a web standalone die without any instruction to do so, and yet give no message nor warning on the server?

During development I have encountered unhandled exceptions. In that case you get a window with a message to help you out. But if you get no message, how do you know what the problem is?

Please help. These 4 different clients are really pissed off, and with good reason.

Are the web apps set to start on boot? Have you checked the machine’s uptime?

Since they are all on OS X you could put a Launchd script in place that just restarts it automatically if it quits
They’re not hard to write a sufficient script

Norman: I have never done a Launchd script. In fact, I stay away from Terminal (by double clicking the app, it gets launched by Terminal). I guess I should learn more about it a some point. Not much of Unix person. Could you send me a sample?

Bob: Yes, the apps are set to start on boot. The uptime can sometimes be a few minutes. Other times many days. How can the uptime affect this issue.

On one server I have two apps running. One app may die and not the other.

[quote=176122:@Jorge Duran-Ballen]Could you send me a sample?
[/quote]
Google is your friend :stuck_out_tongue:
http://alvinalexander.com/mac-os-x/launchd-examples-launchd-plist-file-examples-mac
http://launchd.info
https://developer.apple.com/library/mac/documentation/MacOSX/Conceptual/BPSystemStartup/Chapters/CreatingLaunchdJobs.html

LaunchControal is a great product

Docs

Norman: thanks for those links. Looks like a steep learning curve, though.

Peter: launchd with a GUI … looks nice, and not expensive

Norman and Peter: even if I do get to activate launchd successfully I would only be treating the symptom, not the cause. I still would not know why the apps are quitting in the first place.

Anyone have any ideas? I have the impression that it may be related to user interface. Is there any way that a user can kill/quit the server, either through some mishandled behavior of a web control or some command?

I just repeated a search on my code, and there is no Quit string anywhere in the code. No way I can be executing it by mistake.

[quote=176171:@Jorge Duran-Ballen]Norman: thanks for those links. Looks like a steep learning curve, though.

Peter: launchd with a GUI … looks nice, and not expensive

Norman and Peter: even if I do get to activate launchd successfully I would only be treating the symptom, not the cause. I still would not know why the apps are quitting in the first place.

Anyone have any ideas? I have the impression that it may be related to user interface. Is there any way that a user can kill/quit the server, either through some mishandled behavior of a web control or some command?

I just repeated a search on my code, and there is no Quit string anywhere in the code. No way I can be executing it by mistake.[/quote]

A standalone app will die when the parent process stops. Typically when the terminal is closed. What you describe looks very much like that. How are you starting your app upon launch ?

If I am right, you should be able to see which process stopped just before your app, in the Console.

Do you happen to set autoquit in code ?
That would explain why it shuts off when there’s no activity but by default for standalone apps this is off

If the app is actually crashing then there should be logs visible in the Console application

I had never known about autoquit before, so it was improbable that I had written that. However, I did a global search and there is nothing of the sorts. Plus, the app will just quit while users are using the app. So, idle activity is not the cause. Quite the contrary. It will usually die during user interaction. But none of the users have reported any repetitive situation that kills/quits the server app.

There is no actual crash. I have looked in the crash reports folder.

In my code, I do use a lot of WebContainer, even nesting within others. I also use WebListBox in WebContainers. I also use Threads and Timers. Plus, WebDialogs. But in my mind, even if I were doing something wrong with any of these, it should give an exception, an error, perhaps a Javascript error, or even a crash.

[quote=176196:@Jorge Duran-Ballen]I had never known about autoquit before, so it was improbable that I had written that. However, I did a global search and there is nothing of the sorts. Plus, the app will just quit while users are using the app. So, idle activity is not the cause. Quite the contrary. It will usually die during user interaction. But none of the users have reported any repetitive situation that kills/quits the server app.

There is no actual crash. I have looked in the crash reports folder.

In my code, I do use a lot of WebContainer, even nesting within others. I also use WebListBox in WebContainers. I also use Threads and Timers. Plus, WebDialogs. But in my mind, even if I were doing something wrong with any of these, it should give an exception, an error, perhaps a Javascript error, or even a crash.[/quote]

Absolutely nothing in Console ?

Michel: Thanks for responding.

I am double clicking on the build produced by Xojo. This opens Terminal with a window. If I were to close that window, yes, that would kill the app, just like I am describing. I was even wondering if someone is closing the window while I am not looking. But this is happening at all four of my clients’ servers, which do not know each other. Plus the servers have no monitor nor keyboard nor mouse. I manage them through Screen Sharing, with their respective password that nobody else knows.

What do you mean by this?

Console is an app in OSX. It’s in applications -> utilities. Look for any messages about your app there (likely identified by the bundle identifier).

I did not know about that application. Apparently there are crashes. Several of them. Not sure how to interpret those reports.

Ok. So you guys showed me where all the crash reports are stored. Many thanks for that. But, I have no idea how to read those reports. Too much information, that I know almost nothing about.

From what little I can deduce, in each crash there is a thread that cause the crash. But why, no idea? Is there any help I could find to review those crash reports and help me find a diagnostic?

In this case uptime is referring to the Unix command which returns how long the system has been running.

Add them to a Feedback case so that someone can look into them. Until someone looks at them it is hard to know if it is an issue in Xojo or your code.

Something I’d look at is memory consumption. Apps will just up and die if they run out of available RAM… like if they have a memory leak.

Post one of the crash reports here so we can take a look for you.