We have had a strange issue over the last 6 or 8 months with regards to the error in the subject line. Over the time span of 1 month the number of open SMB connections from the VisualCron server to another server increases to the point where the software can no longer run programs. The fix has been to reboot the VisualCron server which clears the connections and then we are ok for a month or so. I have a powershell script running via windows task scheduler that runs netstat every 30 minutes and stores the connections into a text file. The results are as follows:

2013-11-08: We reached the point where we needed to reboot the server. At that time there were 720 open connections to one server according to netstat.

2013-11-15: 191 connections

2013-11-22: 454 connections

2013-11-29: 675 connections

2013-11-30: We reached the point where we needed to reboot the server. At that time there were 697 open connections to one server.

As you can see, over the course of 22 days the number of SMB connections steadily increases. All of the connections are owned by PID 4 (System process id). I cannot find the link however there was an article I read where hanging SMB connections are grabbed by the system which explains why PID 4 is the owner.

My question is whether we are executing the programs incorrectly via VisualCron which is causing the connections to stay open. The majority of our programs are Foxpro and take a program stored on the network as a parameter. Example: C:\Program Files (x86)\Microsoft Visual Foxpro 9\vfp9.exe and then in the arguments box of the execute job we have "\\server\share\folder\example_program.prg".

Does anyone else have some troubleshooting tips on how we can narrow down what is causing this?

Thanks,

Peter

We have had a strange issue over the last 6 or 8 months with regards to the error in the subject line. Over the time span of 1 month the number of open SMB connections from the VisualCron server to another server increases to the point where the software can no longer run programs. The fix has been to reboot the VisualCron server which clears the connections and then we are ok for a month or so. I have a powershell script running via windows task scheduler that runs netstat every 30 minutes and stores the connections into a text file. The results are as follows:

2013-11-08: We reached the point where we needed to reboot the server. At that time there were 720 open connections to one server according to netstat.

2013-11-15: 191 connections

2013-11-22: 454 connections

2013-11-29: 675 connections

2013-11-30: We reached the point where we needed to reboot the server. At that time there were 697 open connections to one server.

As you can see, over the course of 22 days the number of SMB connections steadily increases. All of the connections are owned by PID 4 (System process id). I cannot find the link however there was an article I read where hanging SMB connections are grabbed by the system which explains why PID 4 is the owner.

My question is whether we are executing the programs incorrectly via VisualCron which is causing the connections to stay open. The majority of our programs are Foxpro and take a program stored on the network as a parameter. Example: C:\Program Files (x86)\Microsoft Visual Foxpro 9\vfp9.exe and then in the arguments box of the execute job we have "\\server\share\folder\example_program.prg".

Does anyone else have some troubleshooting tips on how we can narrow down what is causing this?

Thanks,

Peter

Hi Peter,

is it possible that you could install VisualCron on another server (you have 45 days of trial which we can extend during the test).

First, we would like to deactivate and move about have of the Jobs to another server and then look at the stats. Depending on result we either another half back or forward to see if there is a specific exe that causes this or a specific type of Task.

---

Hi Peter,

is it possible that you could install VisualCron on another server (you have 45 days of trial which we can extend during the test).

First, we would like to deactivate and move about have of the Jobs to another server and then look at the stats. Depending on result we either another half back or forward to see if there is a specific exe that causes this or a specific type of Task.

Hello,

Our office was thinking the same thing. We will discuss implementing this sometime in January. Unfortunately with us upgrading other systems this weekend we will not have a chance to allocate resources until next month so I will mark this topic as resolved until we have had a chance to try and migrate half the jobs to a new server.

Thanks,

Peter

Hello Henrik,

Unfortunately we had other priorities at the office and we weren't able to isolate the issue before the trial expired. We now have the time to investigate more thoroughly. Would it be possible to extend the trial version another 30 or 45 days?

Thanks,

Peter

PM sent

---