Oops, sorry, I told you the wrong thing. It should be:

?

TWS_PATH=/mnt/efs/Jts/

?

But it also looks like you’ve installed Gateway into a non-standard location. These ‘missing’ files should be in

?

/mnt/efs/Jts/ibgateway/1021

?

This is where they will be if you install Gateway to the default location offered by the installer. The scripts depend on Gateway being installed to that default. There is no good reason to put it anywhere else.

?

So I suggest you uninstall Gateway and reinstall to the default.

?

By the way, you don’t need to install both TWS and Gateway: both installers put the same files on the system, apart from the desktop link (which IBC doesn’t use).? They install to different locations, but the IBC scripts know about this and will find whichever one is there. The User Guide does actually tell you this.

This line in gatewaystart_7496.sh is incorrect:

?

TWS_PATH=/mnt/efs/ibgateway/Jts/ibgateway

?

It should be:

?

TWS_PATH=/mnt/efs/ibgateway/Jts/

?

?

?

I did notice that you said you’d changed the value to 100s, and that it didn’t help. Let me explain a bit more about this setting.

?

The reason the setting is there at all is that on rare occasions, TWS doesn’t start up properly after 2FA. Without this mechanism, IBC would just sit there forever waiting for TWS, and if the user was remote with no access to the computer running TWS, there would be nothing they could do to get things going again. Moreover, they would be unaware that anything was wrong, because they had actually successfully completed the 2FA. So this mechanism enables IBC to be automatically restarted in these circumstances.

?

(By the way, I’ve no idea whether this failure to start still happens, but it certainly did at the time I introduced the setting.)

?

It’s also the case that the time taken to start TWS can sometimes be much longer than usual, but it does actually still start eventually if left long enough. Presumably this is due to some condition in the IB servers, and this is what I’ve been experiencing recently. But in the past it has not been common for this condition to persist for long periods. So there’s a trade-off between making the setting very large (say 5 minutes) which should capture the cases where it really isn’t going to start, and making it fairly short so that a retry happens reasonably quickly. The current default of 40 seconds has been a reasonable compromise so far, but maybe something has changed permanently at IB’s end and it’ll need to be raised.

?

So having set my value to 100 secs, I’ll be watching carefully to see how long it’s actually taking in future. This is easy to see in the logfile. Here’s an extract from a successful login last night, after I had upped the setting to 100s:

?

2023-02-13 23:05:23:702 IBC: Click button: Log In

2023-02-13 23:05:24:042 IBC: Button now disabled: Log In

2023-02-13 23:05:34:320 IBC: Detected dialog entitled: Second Factor Authentication; event=Closed

2023-02-13 23:05:34:333 IBC: Duration since login: 10 seconds

2023-02-13 23:05:34:334 IBC: If login has not completed, IBC will exit in 100 seconds

LogModuleConfigurator-Init: Log4j Ver2.x found on classpath

LogModuleConfigurator-Init: LogModuleConfigurator initialized with Log4j Verd.x

2023-02-13 23:06:22:010 IBC: Detected frame entitled: Login; event=Lost focus

2023-02-13 23:06:22:011 IBC: Detected frame entitled: Login; event=Deactivated

2023-02-13 23:06:22:203 IBC: Detected frame entitled: U95482 Interactive Brokers; event=Activated

2023-02-13 23:06:22:222 IBC: Detected frame entitled: U95482 Interactive Brokers; event=Focused

2023-02-13 23:06:22:222 IBC: Detected frame entitled: U95482 Interactive Brokers; event=Opened

2023-02-13 23:06:22:223 IBC: Found TWS main window

2023-02-13 23:06:22:223 IBC: Login has completed

?

IBC detected that the Second Factor Authentication dialog was closed (by TWS) at 23:05:34:320 – this is just after the acknowledgement of the alert on the phone. At 23:05:34:334, IBC starts its wait for the main window to appear, and as the message says, it wants this to happen within 100 seconds.

?

The main window (with the title “U95482 Interactive Brokers”) actually notified its ‘Opened’ event at 23:06:22:222 and IBC recognised this as meaning that login had completed. So in this case it took about 46 seconds from the time of 2FA acknowledgement to the main window being opened. Had I not changed the setting value from the default of 40 secs, this attempt would have failed.

?

I suspect that in your case, the IB server was in one of those conditions that causes the long delay, so if the setting was high enough TWS would eventually have loaded. Or it might have been a ‘never going to happen’ case. The only certain thing is that TWS hadn’t loaded the main window within 40 seconds.

?

Richard

I’m not entirely clear what you’re asking.

?

Please can you clarify. Also attach a sample IBC logfile so I can see what settings you’re using.

?

IBC works exactly the same on Linux as on Windows. You can use cron to provide a backstop restart capability to protect against certain types of failure: but the daily auto-restart governed by the AutoRestartTime setting in config.ini doesn’t need anything additional. For usage of cron with IBC, see the section on ‘Running with crontab (Linux only)’ towards the back of the User Guide.

?

I won’t be responding further tonight as it’s getting late here in the UK, but will follow up tomorrow if need be.

?

?

Ok, this is just a result of TWS taking a long time to display the main form after a 2FA login.

?

The way to avoid this is to set SecondFactorAuthenticationExitInterval in config.ini to a larger value. The default value for this is 40 seconds. IBC expects TWS’s main form to be loaded before this time has expired after IBC has detected the 2FA completion. But for whatever reason, TWS seems to be taking longer than this to load on my computer so far this week. So I set mine to:

?

SecondFactorAuthenticationExitInterval=100

?

and then it worked fine.

?

(By the way, don’t confuse this setting with SecondFactorAuthenticationTimeout, which has a completely different function and should not be changed.)

I experienced the same issue last night.

?

I’ll try to investigate this later today.

?

By the way, for future reference, it’s always helpful to give as much information as possible. For example, you don’t say which version of IBC and TWS you’re using.

?

The easiest way to do this is to attach the IBC logfile, which contains a ton of information that can save me hours in diagnosing issues. That’s why the file exists!

?

Richard

?

?

Just create a socket connection, send the command, read the response, close the connection. I’m not a Pythonista, but I imagine this will be pretty straightforward.

?

?

The screenshot shows that the first task is being stopped at 03:36:57 because it reaches its timeout. That means that when the next schedule start arrives at 03:42:01, it is no longer running, so a new task is started and this will be a new launch of TWS, and hence a full login.

?

There shouldn’t be any time limits to the tasks. If you think about the normal case where the thing loads up on Sunday and keeps running (and auto-restarting daily) all week, that is all the one task (the task being the instance of the batch file, not the instance of TWS which of course is reloaded each day at restart).

?

You don’t need the task start time and the auto-restart time to be the same. It won’t help if the task has a defined timeout.

?

By the way, launcher.log is not really relevant, as it contains no information relevant to IBC. The IBC logfile is much more useful.

?

?

?

?