Socket number (0) illegal or socket not open

[Nikolay]

Colleagues, hello. Again, we have a problem with the connection of the system to the controllers. This time the error is related to sockets.

Code: Select all

WCCOActrl (3), 2018.05.16 13: 57: 05.213, CTRL, WARNING, 2 / ctrl, synchronization.ctl Line: 61: tcpWrite: Socket number (0) illegal or socket not open.
WCCOActrl3: ["connect to"] ["W101"] ["10.10.10.10"] [- 1] [2018.05.16 13: 57: 05.213000000]
WCCILdata (0), 2018.05.16 13: 57: 06.787, SYS, INFO, 39, Connection lost, MAN: (SYS: 1 Ctrl -num 3 CONN: 1), Connection closed
WCCILevent (0), 2018.05.16 13: 57: 06.787, SYS, INFO, 39, Connection lost, MAN: (SYS: 1 Ctrl -num 3 CONN: 1), Connection closed
WCCOActrl3: (process: 26286): GLib-ERROR **: Creating pipes for GWakeup: Too many open files

What do you advise? https://www.winccoa.com/fileadmin/image ... s/code.txt

[leoknipp]

In Linux you can define the number of open "file handles" for every process. It looks like the CTRL manager with number 3 has reached the limit.
Please check if the number for the file handles is increasing when the running the CTRL manager.

Best Regards
Leopold Knipp
Senior Support Specialist

[Nikolay]

It seems that with the number of available open files everything is all right. I work under the operating system OpenSuse 13.2

[Nikolay]

A solution is found! It was necessary to write in the file:

/etc/security/limits.conf

The following information:

root hard nofile 500000
root soft nofile 500000

The root user can now use 500,000 files.

[mkoller]

I had a quick look into the script.
If this is not just a quick example script but used on your production system, you should change it.
The while(1) loop in your main function is a busy loop, which will heavily load the system - not good.
Instead, use a dpQueryConnectSingle() and react on the changed conn_state DP-Element to trigger the callback.

Also: why is it needed to have half a million file descriptors open ???
You can check the current open file descriptors in /proc//fd

[Nikolay]

Our synchronization script with the controllers just sets the conn_state state. The scheme is such that the script checks when the variable conn_state was last changed (stime parameter), and if the difference between the current time and the last time of the conn_state change is more than 150 seconds, then the modbus synchronization request with the controller is sent. The catch is that we have a whole bunch of objects, accordingly we have many conn_state variables. And how do we use dpQueryConnectSingle? A half a million open descriptors, I gave an example, just wanted to share with people a function that will increase this threshold.

[mkoller]

The dpQueryConnectSingle() would look like in the following script:.
The conn_state_CB callback is started whenever any conn_state DPE changes, and in the shown example below you can see how I access the timestamp of the value changed
which you can then use to do your time comparison and you would call then eventually your connect_wells_agp1() function.
I don't know if that is feasible in your situation, but if you just would use the tcpOpen() in the conn_state_CB function, which is automatically serialized with all other
changing conn_state DPEs, then you would end up needing only one tcp filedescriptor. If that's not possible, then stick with the startThread approach you already use, but still use
the query-connect instead of a busy loop in main.

Code: Select all

main()
{
  dpQueryConnectSingle("conn_state_CB", false, "query1",
                       "SELECT '_original.._stime' FROM '*.conn_state'");
}

conn_state_CB(string id, dyn_dyn_anytype tab)
{
  DebugN("DPE", tab[2][1], "timestamp", tab[2][2]);
}