By the way, I noticed that you said “running start_tws.bat”. But IBC doesn’t have a .bat file of that name. Did you mean StartTWS.bat? Or is this another .bat file from somewhere else?

I can’t possibly tell anything from that.

?

Please attach your IBC logfile to your reply (that’s the logfile whose name is shown in the banner window when you start IBC). This file contains a mass of information that can help.

?

Richard

?

?

If I understand you correctly, when you run your live IBC/Gateway, it starts up OK (as per the logfile you sent me), your application (which uses ib_insync) makes a series of API connections to Gateway, and they succeed until another attempt where IBC/Gateway just vanish?

?

Here are some suggestions for investigation:

?

• I assume the application uses the same client id each time it connects? So it should presumably disconnect before it connects again. Make sure that these disconnects are happening correctly: if an API client connects with a client id that is already in use, Gateway doesn’t give a sensible error message like it used to in old versions. For example with IB’s C# API it appears to connect ok, but just hangs when the client tries to request anything. ib_insybc ?doesn’t use the C# client, it has its own Python implementation, and I don’t know what it does in these circumstances. But I can’t really see that it could make Gateway crash, but it’s a thought.
• More likely is that something is actively killing the Gateway. You said that you have something that kills existing Gateways during your startup script: is it possible that this is being run inadvertently?
• If the Gateway encountered a Java exception due to a program fault, that exception would be probably be logged by Gateway. You could look at the Gateway logs – use the File | Gateway Logs menu entry to export them. Look at the end of the latest logfile after the problem happens.

?

I can’t really suggest anything else. IBC is almost certainly not the cause: if it exits for any reason, it writes something to its logfile first. Besides, once it’s got Gateway going and logon has completed, it doesn’t do anything at all unless Gateway displays a dialog that it’s interested in. And gain, if there was a fault while IBC is processing such a dialog, it would be logged before IBC exits.

?

Upgrading to a later version of Gateway might help.

?

?

Oh, sorry, I forgot that I haven’t actually done a new release since pushing the script to GitrHub.

?

You’ll find it in

?

?

and you’ll also need the commandsend.sh script as well.

?

?

?

Let’s start with the easy stuff: how to shutdown Gateway tidily. Obviously if the GUI is accessible you can just click on the close button, so the question is what to do when that isn’t possible (eg remote headless server).

?

There are two options

?

• If you want to close it tidily regularly at a particular time, for example at the weekend to ensure compliance with IB’s Sunday shutdown rule, then you can just use the ClosedownAt setting in config.ini
• If you want to shut it down at random times, you can use the stop.sh script included in the zip file

?

I’m not quite sure what you mean by your ‘restart script’. ?Is this something you use at the start of the week to get it all going, and then use auto-restart for the rest of the week? Or do you run it every day? Not that it really makes much difference, just want to be clear that I know what you’re doing. Oh, I see that you have AutoRestartTime=08:00 PM in your config.ini, so I guess that answers that question.

?

The last line in your logfile says:

?

addLogConsole Client 201

?

I’ve no idea what this is, and I can’t find a method with that name anywhere (and neither can CoPilot). Do you know what this is? Being the last entry, it may well have something to do with your problem

?

Otherwise, I don’t think there’s anything I can do to help.

?

Oh, but wait: it is presumably a message output by Gateway to stdout or stderr: all such messages are redirected to IBC’s logfile. I don’t often use Gateway, but I think it has an option to write its log output to a log tab on the main window. Maybe that is turned on and is causing a problem? Trouble is, I don’t suppose you can see the GUI to check! Can you connect to the GUI with VNC, and turn it off if it is on (there’s not much point in it being on if you can’t see it).

?

?

?

I don’t see anything unexpected in this logfile at all. So I’m not sure what the problem is.

?

Everything seems to have worked perfectly so far. Is this the whole of the logfile? It seems rather odd that it just ends so abruptly. But certainly IBC seems to be behaving itself.

?

When are you getting timeout errors? How do they manifest?

?

?

?

Ok, there’s a couple of things here:

?

1. You’ve probably noticed that the log file is full of lines containing “java.io.IOException: write beyond end of stream”. These are errors thrown by TWS when attempting to write to its logfile: the exceptions are written out to StdErr, and they are redirected into the IBC log file.

?

I’ve seen these in other logs now and again, and I don’t know what the cause is – certainly nothing IBC can do anything about. It’s possible they’re due to some incorrect settings in TWS’s settings file, possibly incorrectly set by IBKR.

?

The only suggestion I can make for that is to ensure you have installed the latest version of TWS 1019: this is version 10.19.2i – it may well be a bug in your version that has since been fixed.

?

2. Regarding the screenshot, I suspect that the problem here is that you’re letting TWS run through Sunday without shutting it down. The rule is that you must shut down TWS completely at some point during Sunday. If you don’t do this, it will try to auto-restart using expired credentials, and then it just defaults to normal full login requiring user id and password to be entered. IBC can’t do this automatically in this case because it thinks it’s in a restart situation, in which case it ignores the login dialog completely.

?

The simplest way to ensure that TWS is closed down on Sunday is to use the ClosedownAt setting in config.ini, like this:

?

ClosedownAt=Sunday 15:00

?

The next release of IBC will contain a new setting that will cause IBC to shut down TWS at a specified time on Sunday (like the above ClosedownAt setting) and then automatically restart it. Full 2FA login will then (of course) be needed, but it means that you wouldn’t need to make arrangements to restart TWS yourself

?

Richard

I’ll just say exactly what I said to you on 27 Jan:

?

Send me the IBC logfile…

?

(see /g/ibcalpha/message/2206)

?

?

?