cannot connect to Web Application anymore

I had a webapp compiled with xojo 2016.1.1 running as standalone application on a Suse Linux SLES11.3 Server on Port 13010.
It’s running in daemon mode and it was running fine for some weeks.
Some days ago it stopped working so that I cannot connect to the port anymore.

The application is starting properly. It’s writing lines in the logfile and it seems to be waiting for connections.
Netstat tells me that the application is using port 13010. Strace is showing me that the application is going into a listen/sleep loop and is waiting for connections.
Telnet from localhost can connect to the application, it’s just not getting any response.

TCPDump tells me that the connections are reaching the server on port 13010 but they aren’t getting answered from the application.
There is no firewall, no proxy, there was no update and nothing was changed on the server for weeks.

To make the search for the error easier I compiled a very simple webapp which is listening on port 13020 and has just the main page with some text.
This application is showing the same behaviour. It’s listening on the given port (13020) but it’s not answering the requests.

All the permissions are set properly (it was already running for weeks), all libraries are installed.

Is there anybody who has a solution for this?

Does it run locally in the debugger?

It’s running in the local debugger, it’s running on other servers with OpenSuse11.3.
I’m currently testing with a pretty simple 32 bit webapplication, now. I just opnened a new web project with just one page.
On that main page there is just one word “testpage” and that’s all.

I’ve tried to run it on different ports, under different users… it’s all the same.
A simple webserver running under python is running fine on the very same port.

Everything you have described sounds like there’s a problem with the server itself.

CPU is almost idle.
There is enough free memory.
There is enough space left in the file system.
There was no change for the last weeks on that server.

[quote=266867:@Mario Schweda]CPU is almost idle.
There is enough free memory.
There is enough space left in the file system.
There was no change for the last weeks on that server.[/quote]
But you also said that the app runs fine on another server, correct?

Did you rebuild the app with a newer version of Xojo?

There is no doubt that is has something to do with the server.
That’s what I was talking about in the first place.
Even a simple web application which displays only one webpage is not accessible.

[quote=266870:@Mario Schweda]There is no doubt that is has something to do with the server.
That’s what I was talking about in the first place.
Even a simple web application which displays only one webpage is not accessible.[/quote]

Have you restarted the server ?

[quote=266870:@Mario Schweda]There is no doubt that is has something to do with the server.
That’s what I was talking about in the first place.
Even a simple web application which displays only one webpage is not accessible.[/quote]
You might want to look in the system logs and see if it’s crashing when a user attempts to connect. That would do what you’re seeing.

I can’t just restart the server. It is a production server.
There has to be another way to fix the problem.
At least I have to know what exactly is causing the problem to make sure that the restart will fix it.

There is only one Errormessage in /var/log/messages:

May 19 10:18:49 sarge kernel: [36268954.909909] modselfservice[1881]: segfault at ff50cffc ip 00000000f70c2c37 sp 00000000ff50d000 error 6 in XojoConsoleFramework32.
so[f6f05000+656000]

Unfortunately there is no way to get Xojo to be a bit more chatty.
My own logging function just tells me that the application is running.

So it was the wrong decision to use Xojo “PRO” in a professional environment.
I guess we are going to switch to something more professional.

So there’s something wrong with the server and yet you blame Xojo for it?
Strange way of thinking but in the end, it’s your decision :slight_smile:

Well, every other piece of software on that server is running without any error.
The segfault error in XojoConsoleFramework32 tells me that there is something wrong with that library.
In a professional environment you cannot restart servers like you do it with a windows computer to see if it fixes a problem.
So there has to be more logging capability to get the root course of the problem before I restart the production server.

It it easy to blame the server because it’s always an easy way out for any software developer.

Come on. Restarting the server happens all the time all over. Sure, php and Perl scripts won’t be an issue since they usually run and terminate. More complex pieces of software may sometimes encounter conditions you, the programmer, did not envision, and that is called a bug. Not always Xojo’s BTW.

A bad workman always blames his tools.

Have you contacted tech support directly? This isn’t it, if you weren’t aware. And you only reported the segfault after a reboot was suggested. You began the thread by asserting that nothing has changed on the server. That can’t possibly be the case. You’re going to have to work with the Xojo engineers to get to the bottom of this.

Thanks Tim, I will do that.

[quote=266880:@Mario Schweda]There is only one Errormessage in /var/log/messages:

May 19 10:18:49 sarge kernel: [36268954.909909] modselfservice[1881]: segfault at ff50cffc ip 00000000f70c2c37 sp 00000000ff50d000 error 6 in XojoConsoleFramework32.
so[f6f05000+656000][/quote]
In my experience, a segfault like this means that your app is running out of RAM and crashing.

There is plenty of ram in the server. That’s the odd thing.
I was suspecting the same, either RAM, file space or CPU. Since this is an important production server, which is very well monitored, there is plenty of file space, RAM and CPU.
I also checked the inodes, but there is also plenty left.
Is there any possibility to enable a verbose logging for xojo? Beside my own logging there is no logging of xojo itself.

There are some command line options, including where to write logs, but no amount of verbose logging from within the app is going to tell you why it crashes like this.

Have you implemented App.unhandledException to see if you’ve got a code problem?

The only other thing that comes to mind is permissions. It could be that the libs folder permissions or the libs themselves are not set to be executable. Also, if you’re using selinux, make sure it’s not terminating the app.