Ours have been goign on and off line all week. I have a case open and they are telling me its my server - which seems to be running fine

Legacy Forum Name: General Discussion,
Legacy Posted By Username: tlblv

I had them go offline a couple of times yesterday and once today (so far)

Legacy Forum Name: General Discussion,
Legacy Posted By Username: boudj

So far twice today.

On the most recent occurence I was able to see that all the client connections to the VSA port (5721 by default) are at a status of CLOSE_WAIT. A Google search indicates this happens when the Server app does not close down the connection cleanly. I was able to quickly reestablish connections by killing the adapter and bringing it back up (in other words, manually forcing the connections to close fully). Of course, this won't work overnight when I am unable to physically access the server.

From this it appears the problem is that the Kaseya app simply stops replying to client requests but doesn't fully close the sessions and clients are unable to establish a new one.

Legacy Forum Name: General Discussion,
Legacy Posted By Username: karode

Here is the best summary explanation I can find for close_wait. Looks like the resolution until the application is fixed is to stop and restart the services to clear the port. I expect it will arise again and I will try that.

The problem is that your application is not closing the socket now that the other host has closed its socket. That's what CLOSE_WAIT means, namely that the OS is waiting for the application to close the socket.

There are numerous reasons that the application isn't closing the socket, almost all of them are because of application bugs. There are a few ways that the application can be informed that the other end has closed the socket. The most common is to try to read the socket and get back the EOF indicator, which is a successful read of zero bytes.

Writing to the socket may tell you, but not always. In TCP it is allowed to write on a socket that has been closed on the other end, because in TCP closing the socket says that you will do no more writes, but says nothing about whether or not you will still read. If the socket was closed abortively and no longer exists at all, then the write will return an EPIPE error.

If the protocol that you are using does not allow for reading any data, then use non-blocking sockets and the poll call to tell when the socket is readable without actually blocking in the read call.

The only real possibility that is not a bug in the application is if there is a bug in the OS that prevented it from informing the application that the EOF was available. This is of course unlikely, but not impossible.

Legacy Forum Name: General Discussion,
Legacy Posted By Username: karode

We also took a server offline today for 20 minutes and didn't get an offline alert (We have it set to email/alert after 3 mins offline). I have just tested this on a couple of other non-critical servers and no alerts have been sent from the offline server. This is not good.

Legacy Forum Name: General Discussion,
Legacy Posted By Username: boudj

we are getting this problem today as well... boy am i happy we upgraded to 2008...

not happy kaseya!!!

Legacy Forum Name: General Discussion,
Legacy Posted By Username: KRiSX

All my agents stopped checking in suddenly today.

Restarted the K Server Service, and they started checking in again.

Legacy Forum Name: General Discussion,
Legacy Posted By Username: myArch-man

same happened to us twice today with the agents.

also had a server that went down last night, with alerts set on it to notify us, which no alerts came through. good thing Zenith called to alert me.

Legacy Forum Name: General Discussion,
Legacy Posted By Username: synergyc

We are also getting these problems.
Also we are only recieving e-mails when the server goes online not offline :/ this had been a problem since we put on 2008

Legacy Forum Name: General Discussion,
Legacy Posted By Username: jarrad.leening

We are also experiencing this same problem. Even though never reported as offline, every one of our monitored agents are reported as coming back online all within a minute or two. This has been happening once a day since our upgrade...


Legacy Forum Name: General Discussion,
Legacy Posted By Username: dsecker

It's happening again. The agents are not checking in.

I have other IP connections issues too.

My firewall says there is a SYN flood attack to port 443, but it's really just me doing admin.

Some external monitors setup on the kserver's agent are also failing, but should not be.

These issues have been random, and do not outwardly appear related.

Legacy Forum Name: General Discussion,
Legacy Posted By Username: myArch-man

[QUOTE=myArch-man;27414]It's happening again. The agents are not checking in.

I have other IP connections issues too.

My firewall says there is a SYN flood attack to port 443, but it's really just me doing admin.

Some external monitors setup on the kserver's agent are also failing, but should not be.

These issues have been random, and do not outwardly appear related.[/QUOTE]

Same problem here, restarting service fixed the problem.

Legacy Forum Name: General Discussion,
Legacy Posted By Username: rudi

We have had this happen 3 times today. We have:

1) Applied latest Hotfix (27-Mar-08)
2) ReApplied database Schema
3) Restarted Kaseya service (both in web interface and services.msc)
4) Restarted entire server.

They come online after restarting server, but all go offline after about an hour or so.

Very frustrating!

Legacy Forum Name: General Discussion,
Legacy Posted By Username: bresource

bresource

We have had this happen 3 times today. We have:

1) Applied latest Hotfix (27-Mar-08)
2) ReApplied database Schema
3) Restarted Kaseya service (both in web interface and services.msc)
4) Restarted entire server.

They come online after restarting server, but all go offline after about an hour or so.

Very frustrating!

We have the exact same problem! :/

Legacy Forum Name: General Discussion,
Legacy Posted By Username: jarrad.leening