socat connection timed out

[rubenbriones]

After about 4h of running the docker container, and being working perfectly, it starts to log the following message every 5 minutes:

2022/12/22 21:27:11 socat[956] E connect(5, AF=2 127.0.0.1:4000, 16): Connection timed out
2022/12/22 21:32:12 socat[964] E connect(5, AF=2 127.0.0.1:4000, 16): Connection timed out
2022/12/22 21:37:11 socat[973] E connect(5, AF=2 127.0.0.1:4000, 16): Connection timed out
...

Until the nightly reboot happens, which is performed correctly, and it stops logging that time out. Until about 4 hours pass again, and then it logs the same timeout message every 5 minutes:

2022-12-22 23:45:38:448 IBC: Performing port configuration
2022-12-22 23:45:38:807 IBC: TWS API socket port is already set to 4000
2022-12-22 23:45:38:807 IBC: Setting ReadOnlyApi
2022-12-22 23:45:38:808 IBC: Read-Only API checkbox is already set to: false
2022-12-22 23:45:38:820 IBC: Click button: OK
2022-12-22 23:45:39:321 IBC: Detected dialog entitled: DUXXXXXX Trader Workstation Configuration (Simulated Trading); event=Lost focus
2022-12-22 23:45:39:322 IBC: Detected dialog entitled: DUXXXXXX Trader Workstation Configuration (Simulated Trading); event=Deactivated
2022-12-22 23:45:39:323 IBC: Detected dialog entitled: DUXXXXXX Trader Workstation Configuration (Simulated Trading); event=Closed
Forking :::4000 onto 0.0.0.0:4002
remove Client 0
2022/12/23 04:12:13 socat[759] E connect(5, AF=2 127.0.0.1:4000, 16): Connection timed out
2022/12/23 04:17:12 socat[768] E connect(5, AF=2 127.0.0.1:4000, 16): Connection timed out
2022/12/23 04:22:11 socat[778] E connect(5, AF=2 127.0.0.1:4000, 16): Connection timed out
2022/12/23 04:27:12 socat[787] E connect(5, AF=2 127.0.0.1:4000, 16): Connection timed out
...

Any idea why it could be? I have seen that in other repo put the forever option in the socat command, can that be the solution?

And, another question, why is the fork_ports_delayed.sh script necessary? And why is it necessary to run it with a delay of 30s? My knowledge about IBGateway and docker is limited, but I would like to understand the reason for this script. I have also seen that in this other repo they say that with the network_mode: host option of docker this file is no longer necessary. I do not know if it is true or not, since as I say my knowledge about docker is scarce. But I comment it in case it is of help.

Thank you very much for continuing to maintain this project.

[efernandesng]

Hi, sorry for the delayed reply. Thank you for your detailed issue and interesting questions.

Regarding the socat connection problem, it can be caused by a couple of reasons, but it looks like the IB-Gateway closes itself after some time. I don't have sure, it can be some account setting (e.g. auto-restart) which is applied when you log in with your account. To test that, you can run the IB-Gateway locally on your machine and confirm if it has the same behavior. Anyway, I can try to reproduce the problem, I only need to know the image tag (including digest) which you are using.

Any idea why it could be? I have seen that in other repo put the forever option in the socat command, can that be the solution?

Interesting, I'll investigate.

And, another question, why is the fork_ports_delayed.sh script necessary? And why is it necessary to run it with a delay of 30s?

The 30-second sleep is to give time to the ib-gateway to properly starts. But it can be improved, maybe using something like the wait-for-it.sh script.

I have also seen that in this other repo they say that with the network_mode: host option of docker this file is no longer necessary.

Yes, but it may be a problem if you want to use another docker network mode (e.g. brigde). I'll explore that.

[rubenbriones]

Thank you very much for your answer @efernandesng! The image I am using is the latest: sha256:c7fc3739e1b09ed10ea4da099508410535eff193e7433bd4774695a3bd996c22.

But it seems that as you say it must be something specific to my account, because I have tried to run that same image with another IB account, on the same machine, and in this second account I doesn't get that timeout log. I am going to see if I can see what configuration both accounts have different.

[maciejmaz]

Hello, Do you have any ideas what might be causing this issue? I've deployed ibgateway on kubernetes cluster and it was working correct for the last two weeks, but since few days ago it started to return connect(5, AF=2 127.0.0.1:4000, 16): Connection timed out error message. I've even set up new account, but it didn't help.

--- edit It looks like it's now working. ReadinessProbe on Kubernetes was set up to verify the connection on port 4002 and it was locking all the other connections.