I can absolutely guarantee that there is no way that gatewaystart.sh would start two instances of Gateway, and you haven’t provided any evidence or illustrations of what you mean.

?

So please do this:

?

1. Make sure there are no instances Gateway running.
2. Run gatewaystart.sh again.
3. Attach the IBC logfile to your reply (don’t just paste the text into your message, an attached file is much easier to work with).
4. Perhaps attach a screenshot as well to show what you mean.

?

Richard

I don’t have any suggestions to make.

?

Let me clarify something. IBC is behaving exactly as it should here. It is expecting Gateway to display the login dialog within the specified timeout period. If it doesn’t happen within that time, IBC closes down and the IBC script restarts it. There is a reason for this: in rare circumstances, some condition in the IB servers prevents the login dialog being displayed, but trying again succeeds. I’ve no idea what the cause of this is, or even whether it still happens (other than the large initial download, as mentioned before), but when it does happen IBC’s restart mechanism means the login automation is not broken.

?

But clearly you aren’t in this large download scenario, and it is something else that is preventing Gateway displaying the login dialog. That ‘something’ cannot be IBC. As I said before, it’s possibly something to do with the JavaFX setup, because displaying the login dialog is the first thing that uses JavaFX.

?

Actually I do have one suggestion: when Gateway runs, it writes log entries to an unencrypted text file called launcher.log, which you should find in /home/ibgateway/Jts. There may well be some information about what’s happening recorded there.

?

I’m sorry I can’t be more help.

?

Richard

Sorry, I saw this on Sunday and then completely forgot about it.

?

The exit code 1112 in your IBC logfile occurs when the Gateway login dialog has not been displayed within the time specified in LoginDialogDisplayTimeout in config.ini.

?

The most likely cause of this (if it was working before) is that this timeout is too short. When it starts up, Gateway downloads a ton of stuff, including the JxBrowser web browser. For a low-power machine like a Pi, it may just not be able to process this stuff quickly enough. So try increasing the value, perhaps to 90 secs, or even longer if that doesn’t help.

?

If extending the timeout doesn’t help no matter what value you use, it probably means that there is something not right about the JavaFX setup.

?

Richard

?

?

?

Jonathan

?

You (and others) refer to ‘Gonzalo’s Docker image’, but without any explanation as to who Gonzalo is and where his Docker image is to be found. Please fill me in.

?

I need to point out that there is no benefit as far as IBC and Gateway are concerned in trying to upgrade to ‘the latest possible JRE version’. The simple fact is that both Gateway and IBC are built using Java 8: neither use any feature from later Java versions. I develop IBC with the same JRE as IBKR do for Gateway and TWS, because it means I can rely on the identical version in all IBC instances, thus potentially avoiding problems where different users use different versions. IBKR has used the same version of Java 8 for several years now, presumably for much the same reason. If they were to switch to a later version they would end up with possible support nightmare: whether this would actually be the case is debatable, but for many years it was the user’s responsibility to maintain their own JRE installation: I suspect that was a bad experience for IBKR, and the current mechanism, where the same JRE they use is automatically included by the installer and any other JRE on the machine is ignored, made life simpler for them.

?

It’s possible that eventually there’ll be some new feature in a later Java version that IBKR can’t do without, and then they’ll feel the need to develop against that version and adjust the installer according (and face the support problems that will occur when the two get out of step). But they show no signs of this at the moment. Presumably Java 8 does everything they need. But ?if and when this happens, then I’ll switch to the same JRE for IBC.

?

Richard

I’m really glad to hear you got it working. Well done!

?

I’ve just ordered myself a Pi 5. I read a review in the UK PCPro magazine this morning and was quite impressed by how they’ve progressed over the years.

?

It will be useful in future for making sure IBC continues to work on ARM (assuming I can replicate your success…). I probably won’t use it for running TWS for real, as I don’t want to have yet another computer that has to be powered on 24x7 (even if it is only a few watts).

?

No, I’m not working on a Docker image myself, but various other people are. Of these, the one that seems most promising to me is this one:

?

?

I haven’t used it myself yet, so this is not an ‘official’ endorsement, but the author has clearly put a lot of work into it and appears to have taken account of the various desiderata I expressed some time ago for what an IBC Docker should provide.

?

Richard

?

The pre-packaged JRE is irrelevant. The IBKR installer includes a script to run Gateway that uses the pre-packed JRE, and it also caters for using another JRE, but there’s no reason why you have to run it using that script.

?

All you need is the right Java command to run the Gateway JAR files. And I posted that command in the other thread you spoke on today. Here it is again, adjusted for your pi username:

?

?

java -DjtsConfigDir=/home/pi/Jts -Xmx768m -XX:+UseG1GC -XX:MaxGCPauseMillis=200 -XX:ParallelGCThreads=20 -XX:ConcGCThreads=5 -XX:InitiatingHeapOccupancyPercent=70 -DvmOptionsPath=/home/pi/Jts/ibgateway/1033/ibgateway.vmoptions -Dsun.awt.nopixfmt=true -Dsun.java2d.noddraw=true -Dswing.boldMetal=false -Dsun.locale.formatasdefault=true -classpath /home/pi/Jts/ibgateway/1033/jars/jackson-databind-2.12.3.jar:/home/pi/Jts/ibgateway/1033/jars/log4j-api-2.17.1.jar:/home/pi/Jts/ibgateway/1033/jars/twslaunch-1033.jar:/home/pi/Jts/ibgateway/1033/jars/xmlgraphics-commons-2.8.jar:/home/pi/Jts/ibgateway/1033/jars/jackson-core-2.12.3.jar:/home/pi/Jts/ibgateway/1033/jars/jts4launch-1033.jar:/home/pi/Jts/ibgateway/1033/jars/commons-io-2.11.0.jar:/home/pi/Jts/ibgateway/1033/jars/fop-2.8.jar:/home/pi/Jts/ibgateway/1033/jars/jackson-annotations-2.12.3.jar:/home/pi/Jts/ibgateway/1033/jars/jxbrowser-7.41.3.jar:/home/pi/Jts/ibgateway/1033/jars/batik-all-1.16.jar:/home/pi/Jts/ibgateway/1033/jars/jxbrowser-linux64-7.41.3.jar:/home/pi/Jts/ibgateway/1033/jars/jxbrowser-swing-7.41.3.jar:/home/pi/Jts/ibgateway/1033/jars/log4j-core-2.17.1.jar:/home/pi/Jts/ibgateway/1033/jars/total-2023.jar ibgateway.GWClient

?

?

Running Gateway standalone won’t actually help if the problem is that the login dialog is not being displayed, but at least it will demonstrate that the problem is not being caused by IBC. That most likely indicates an incomplete JavaFX problem on ARM, but I have no expertise in this area, and no access to an ARM platform to investigate it myself.

?

Frankly I’m tempted to just say forget ARM and stick with x64. Everything just works ‘out of the box’. One day someone will crack this on ARM and do a decent write-up of how, but at present it seems we’re not there, and if you don’t have the expertise to move this forward yourself, you could waste a lot of your (and other people’s) time.

?

Richard