Tango starter Host address seen as localhost and then unreachable from other computer

Hello,

Since the release of Tango 9.4.1 Windows installer, I upgraded one of our existing tango database which went fine.

The only issue I currently have is that the starter, which works perfectly from the server it is running on and starts all our devices, is seen as not running from other computers on the network (using astor or jive).

I've noticed that the current host for the starter in jive is displayed as 127.0.0.1 (localhost) instead of the actual name of the server and/or IP address.

Started devices appear to be fine and can be reached and operated without issue and their host is set as "COMPUTER_NAME (COMPUTER IP)", as expected.

Does someone knows why this behaviour is happening?

I shall add that it worked perfectly while the database was in older version 8.2.2 and that it still works if I revert to 8.2.2.
Guillaume DI FRANCO
Thales - Software Engineer Manager
Hi Guillaume,

Do you still have this problem?

How do you start the Starter? As a service?
Are you using a bat file to start it?

Did you try to start it from a terminal? Do you have the same result?

It looks like the IOR stored in the Tango Database for your Starter device does not contain the correct information.
Are you using the correct TANGO_HOST environment variable when you start your Starter device?
Are you using omniORB options like ORBEndPointPublish or ORBendPoint when starting your Starter device?

In jive from another computer, do you see this Starter device as exported in the database?
Is the field "last_exported" set to the correct date and time of the last startup?

Where is your Tango DB running? On the same host as this Starter or another host?

Are you sure your clients running on other hosts are not using TANGO_HOST=localhost:xxxx?

Kind regards,
Reynald
Rosenberg's Law: Software is easy to make, except when you want it to do something new.
Corollary: The only software that's worth making is software that does something new.
Hi Hiro,
Hi Reynald,

I have the same issue to some degree and can reproduce it. Maybe this helps you to debug.

I have two PC's, I will refere to them as A and B.
A runs Windows 10 and B runs Linux Mint 21.1.
A runs a Tango Database and Starter, installed with the Windows Installer for Tango 9.4.1 and started manually with the provided batch files.
B runs a Tango Database and Starter inside a docker container based on the image tango-cs:9 from gitlab and started with docker compose up.

Case 1:
A is the Tango Host and B is the client.

Running Astor on B shows the starter on A as "running". Device servers can be controlled and restarted, everything is OK. The "host" under device info in Jive of the starter on A represents the correct IP from A.

Now the other way around.
Case 2:
B is the Tango Host and A is the client.

Running Astor on A shows the starter on B as "not running". Device servers can not be controlled. The "host" under device info in Jive of the starter on B does not represent the actual IP adress of B. It is 172.19.0.6.

Side note: For case 2, browsing the database with Jive is very slow. Clicking on device servers and properties takes around 5 seconds. For case 1 this is much more responsive, no delay noticeable.

I hope this helps.
Best regards,
Dominik
Edited 11 months ago
Processes running on other hosts cannot connect to processes that run inside Docker containers. This is basic containerisation security. Containers have to either be configured to use Docker's host network mode or all relevant ports of the containers are exposed and the Device Servers that run in the containers are started with the matching -ORBendPointPublish and -ORBendPoint parameters.
Edited 10 months ago
I Reynald,

EDIT 1 : Case solved. I keep the answers bellow with other edits and the explaination of the correction to solve the issue at the end.

Thank you for your messages.
Sorry for the very long delay but the subject went in standby and its priority was at the lowest level.

Reynald
How do you start the Starter? As a service?
Are you using a bat file to start it?
The starter is using a Windows service, which is started using a dedicated script as we have checks that occurs at startup that requires the system to stay still before starting the tango software (DB, Starter etc.)

Reynald
It looks like the IOR stored in the Tango Database for your Starter device does not contain the correct information.

How can I check that? If the IOR was wrong, the Starter shall not be able to connect to the database, get the list of the device servers it controls and run them, shall it?

Reynald
Are you using the correct TANGO_HOST environment variable when you start your Starter device?
Are you using omniORB options like ORBEndPointPublish or ORBendPoint when starting your Starter device?
TANGO_HOST is defined properly on both systems
We also use the TANGO_LISTENING_IP, as usual
We also use the option " -ORBendPoint giop:tcp:%TANGO_LISTENING_IP%:" in our scripts

Reynald
In jive from another computer, do you see this Starter device as exported in the database?
Is the field "last_exported" set to the correct date and time of the last startup?
I'll have to go back to the system to check that information.
EDIT 2 : last_exported field is up to date.

Reynald
Where is your Tango DB running? On the same host as this Starter or another host?
Tango database, Starter and devices all run from the same host.

Reynald
Are you sure your clients running on other hosts are not using TANGO_HOST=localhost:xxxx?
Absolutely sure that the issue is not related to TANGO_HOST.

I will be quite busy the next two months so I may not reply quicky, sorry.
EDIT 3 : I just went back to the system and discovered the solution. For whatever reason, someone changed the Service startup mode from manual to automatic.smile
Then, at startup, the Starter could not reach the Tango Database which was not running. I do not even know if the computer already got its IP when the Starter starts, which may also cause the HOST to be set to 127.0.0.1. I may test the same manually without the Tango DB just to be sure.
I restored the startup mode to manual, rebooted the computer and left the startup script do its job. Everything went OK, so I consider my case as solved smile

Best regards,

Guillaume
Guillaume DI FRANCO
Thales - Software Engineer Manager
Edited 7 months ago
Hi Guillaume,

Great to read you understood the origin of the problem and found a solution!
Thank you very much for having updated this forum topic.

Kind regards,
Rosenberg's Law: Software is easy to make, except when you want it to do something new.
Corollary: The only software that's worth making is software that does something new.
 
Register or login to create to post a reply.