New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and
privacy statement. We’ll occasionally send you account related emails.
Already on GitHub?
Sign in
to your account
Closed
pFernbach opened this issue
Sep 19, 2019
· 19 comments
Comments
Issue originally opened in stonneau/hpp-rbprm#22
When I try to run hpp-rbprm-server I got this:
ORBA: CORBA::Exception TRANSIENT:IDL:omg.org/CORBA/TRANSIENT:1.0 : failed to narrow the root naming context
CORBA: CORBA::SystemException: failed to narrow the root naming context.
terminate called after throwing an instance of 'hpp::Exception'
what(): Failed to start corba server.
Aborted (core dumped)
I got the same errors when running the other corbaserver
Originally posted by @teguhSL in stonneau/hpp-rbprm#22 (comment)
Hi @teguhSL
If you run nameclt list
, do you have any error ?
Originally posted by @nim65s in stonneau/hpp-rbprm#22 (comment)
Running nameclt list
gives me this:
Cannot resolve the root context.
Have you set up the configuration file properly?
ok, is the omniNames
process running ?
Either it is not started (and you can start it with omniNames -start
), or its configuration is not clear (and you can fix that with export NameService=corbaname::localhost
)
Ok, now by following
ok, is the omniNames process running ?
Either it is not started (and you can start it with omniNames -start), or its configuration is not clear (and you can fix that with export NameService=corbaname::localhost)
omniNames is running, and I can run hbb-rbprm-server.
Then I run the following codes from darpa_hyq_path.py
,
from hpp.corbaserver.rbprm.hyq_abstract import Robot
and get these errors:
omniORB: (0) 2019-09-19 16:01:07.669351: ERROR! omniORBpy version 4.2 expects stubs version 4.2. Stubs in /opt/openrobots/lib/python2.7/site-packages/hpp_stubs/corbaserver/obstacle_idl.pyc are version 3.0 (rev 0).
---------------------------------------------------------------------------
ImportError Traceback (most recent call last)
<ipython-input-1-204577a9b00a> in <module>()
----> 1 from hpp.corbaserver.rbprm.hyq_abstract import Robot
/opt/openrobots/lib/python2.7/site-packages/hpp/corbaserver/__init__.py in <module>()
----> 1 from .client import Client
2 from .robot import Robot
3 from .problem_solver import ProblemSolver, newProblem
4 from .tools import loadServerPlugin, createContext
5 from .benchmark import Benchmark
/opt/openrobots/lib/python2.7/site-packages/hpp/corbaserver/client.py in <module>()
6 import CosNaming
7
----> 8 import hpp_idl.hpp.corbaserver
9
10 class CorbaError(Exception):
/opt/openrobots/lib/python2.7/site-packages/hpp_idl/hpp/__init__.py in <module>()
7
8 # ** 1. Stub files contributing to this module
----> 9 import hpp_stubs.corbaserver.obstacle_idl
10 import hpp_stubs.corbaserver.problem_idl
11 import hpp_stubs.corbaserver.robot_idl
/opt/openrobots/lib/python2.7/site-packages/hpp_stubs/corbaserver/obstacle_idl.py in <module>()
5 _0_CORBA = CORBA
6
----> 7 _omnipy.checkVersion(3,0, __file__)
8
9 # #include "hpp/common.idl"
ImportError: Stubs not compatible with omniORBpy version 4.2.
Thanks, I’m starting to understand. Which OS are you using ?
I think you have robotpkg-omniorbpy
, and that you should remove it, to use the standard python-omniorb
package from Ubuntu.
omniORBpy should be on version 3 on 16.04.
I already uninstall robotpkg-omniorbpy
, but I still have the same issue.
Do you mean to remove also robotpkg-omniorb
?
Indeed, I did not have robotpkg-omniorb
after following the installation procedure, so I install it myself by sudo apt-get install robotpkg-omniorb
. Otherwise, calling omniNames results in:
bash: /opt/openrobots/bin/omniNames: No such file or directory
although I have python-omniorb
installed (version (3.6-1))
omniNames
should be in omniorb-nameserver
: /usr/bin/omniNames
After removing robotpkg-omniorb
, apparently I still have two versions of omniNames, in /usr/bin
and /usr/local/bin
. The problem persists, so I remove the one in /usr/local/bin
. However, it seems that I am still running omniorb version 4.
I check /usr/lib
and I have the following files:
libomniORB4.a
libomniORB4.so
libomniORB4.so.1
libomniORB4.so.1.6
How can I downgrade the running omniorbpy from 4.2 to 3.6? I already install 3.6 by sudo apt-get install python-omniorb
and get:
python-omniorb is already the newest version (3.6-1).
But when I run the rb-prm program I still have the same error saying that my omniorbpy is version 4.2.
Having omniorb-nameserver v4.1 & python-omniorb v3.6 is normal.
But if I start a clean 16.04, with robotpkg-hpp-rbprm-corba, python-omniorb, omniorb-nameserver, I can get the following:
In [1]: import _omnipy
In [2]: _omnipy.checkVersion(3,0, "/opt/openrobots/lib/python2.7/site-packages/hpp_stubs/corbaserver/obstacle_idl.py")
without error.
Can you try to see what gives python -c 'import _omnipy; print _omnipy.__file__'
?
For me, that’s /usr/lib/python2.7/dist-packages/_omnipymodule.so
, which is a correct path for python-omniorb
You have to reinstall corba packages (hpp-corbaserver, hpp-rbprm-corba…) because the servers and clients must be regenerated.
Running python -c 'import _omnipy; print _omnipy.__file__'
gives me:
/usr/lib/python2.7/dist-packages/_omnipymodule.so
so I remove this file, and then running the above command now gives me the correct location:
/usr/lib/python2.7/dist-packages/_omnipymodule.so
After this I uninstall and reinstall hpp packages through robotpkg. Running
In [1]: import _omnipy
In [2]: _omnipy.checkVersion(3,0, "/opt/openrobots/lib/python2.7/site-packages/hpp_stubs/corbaserver/obstacle_idl.py")
returns without error, so it seems I have the correct version now.
However, running the codes
from hpp.corbaserver.rbprm.hyq_abstract import Robot
now gives me new error:
omniORB: Assertion failed. This indicates a bug in the application
using omniORB, or maybe in omniORB itself.
file: ../../modules/omnipy.cc
line: 459
info: omniPy::pyomniORBpoaCache
terminate called after throwing an instance of 'omniORB::fatalException'
Aborted (core dumped)
Ok, at this point it might be useful to clean your install and start again…
You can try with sudo apt purge *omni*
and then sudo apt install omniorb omniorb-nameserver python-omniorb python-omniorb-omg
I did what you suggested: purging *omni* and *hpp*, and then reinstall. But the problem still appears:
omniORB: Assertion failed. This indicates a bug in the application
using omniORB, or maybe in omniORB itself.
file: ../../modules/omnipy.cc
line: 459
info: omniPy::pyomniORBpoaCache
terminate called after throwing an instance of 'omniORB::fatalException'
Aborted (core dumped)
If I start a clean 16.04 with robotpkg apt repositories
sudo apt install omniorb omniorb-nameserver python-omniorb python-omniorb-omg robotpkg-hpp-rbprm-corba robotpkg-py27-qt4-hpp-gepetto-viewer
I can execute from hpp.corbaserver.rbprm.hyq_abstract import Robot
without errors.
Without being able to reproduce your issue, it’s hard to find a fix…
Then maybe you can try to reinstall ubuntu.
Hi, I have just tried on a freshly installed ubuntu and the first line works, thank you!
Now the problem is with gepetto_gui, when I launch it I got this:
»’
«omniorbserver.so» : «The shared library was not found.»
Plugin «omniorbserver.so» not loaded: «The shared library was not found.»
»’
I have tried restarting the omniNames but the problem remains
The file omniorbserver.so should be in /opt/openrobots/lib/gepetto-gui-plugins.
- If it is, then your LD_LIBRARY_PATH likely does not contain /opt/openrobots/lib
- If it is not, then you may not have installed it. It should have been installed by the command above. It is part of package robotpkg-py27-qt4-gepetto-viewer-corba
Thank you @jmirabel , now the example is working!
INTELLIGENT WORK FORUMS
FOR COMPUTER PROFESSIONALS
Contact US
Thanks. We have received your request and will respond promptly.
Log In
Come Join Us!
Are you a
Computer / IT professional?
Join Tek-Tips Forums!
- Talk With Other Members
- Be Notified Of Responses
To Your Posts - Keyword Search
- One-Click Access To Your
Favorite Forums - Automated Signatures
On Your Posts - Best Of All, It’s Free!
*Tek-Tips’s functionality depends on members receiving e-mail. By joining you are opting in to receive e-mail.
Posting Guidelines
Promoting, selling, recruiting, coursework and thesis posting is forbidden.
Students Click Here
CORBA::TRANSIENT exception in corba client?CORBA::TRANSIENT exception in corba client?(OP) 27 Oct 08 22:50 i developed a corba client application which sucessfully compiled and started up normally, but the corba connection would be interrupted rulelessly with a CORBA exception described as CORBA::TRANSIENT. Red Flag SubmittedThank you for helping keep Tek-Tips Forums free from inappropriate posts. |
Join Tek-Tips® Today!
Join your peers on the Internet’s largest technical computer professional community.
It’s easy to join and it’s free.
Here’s Why Members Love Tek-Tips Forums:
- Talk To Other Members
- Notification Of Responses To Questions
- Favorite Forums One Click Access
- Keyword Search Of All Posts, And More…
Register now while it’s still free!
Already a member? Close this window and log in.
Join Us Close
Operations Automation
Operations Automation:5.5
Operations Automation:5.x
Operations Automation:6.0
Operations Automation:6.x
Symptoms
Pleks Automation tasks fail with CORBA errors:
-
CORBA/TIMEOUT
-
CORBA/TRANSIENT
- CORBA/COMM_FAILURE
Examples of errors:
-
Destination host 'server1.example.com' (#32), IP '192.0.2.2' : The remote server is temporarily down. Please, make sure that destination host is accessible from POA management node and POA agent is running there. Details: system exception, ID 'IDL:omg.org/CORBA/TRANSIENT:1.0' OMG minor code (2), described as 'No usable profile in IOR.', completed = NO
-
Destination host 'server1.example.com' (#32), IP '192.0.2.2' : Communication failure with remote server. Please, make sure that destination host is accessible from POA management node and POA agent is running there. Details: system exception, ID 'IDL:omg.org/CORBA/COMM_FAILURE:1.0' TAO exception, minor code = 1 (failed to recv request response; ETIMEOUT), completed = MAYBE
-
Request has been timed out, details: system exception, ID 'IDL:omg.org/CORBA/TIMEOUT:1.0' TAO exception, minor code = 79 (timeout during recv; low 7 bits of errno: 121 No error), completed = MAYBE
-
Operation execution is aborted by timeout. Please increase timeout for this operation and try again. Details: system exception, ID 'IDL:omg.org/CORBA/TIMEOUT:1.0' TAO exception, minor code = 3e (timeout during recv; low 7 bits of errno: 62 Timer expired), completed = MAYBE
Cause
The tasks fail as the result of various communication problems between the PA Management Node and managed hosts.
PA uses CORBA (Common Object Request Broker Architecture) technology to communicate with managed hosts through the PA Agent.
NOTICE: /etc/init.d/pem
— This service starts a lots of instances of the process pleskd
. This process is responsible for all PA functionality. Also several instances of pleskd
process are responsible for PA agent which performs communication with PA agents on Service Nodes.
The PA Management Node sends requests to managed hosts to perform required provisioning operations using CORBA requests to the PA Agent, which must be installed on any host registered in and managed by PA.
In the event of problems sending requests to or receiving responses from the PA Agent, whatever the cause, background tasks may fail in PA with CORBA errors.
The most likely causes of communication problems between the PA Management Node and the PA Agent working on managed hosts are.
-
The managed host is down
-
The PA Agent has stopped on the managed host or is stuck
- The PA Management Node cannot establish a connection to the PA Agent on the managed host due to problems with routing or a firewall
Resolution
Make sure the PA Management Node can establish a connection to the PA Agent working on the managed host, send a request to the PA Agent, and receive a response from it.
Follow the troubleshooting steps:
-
Restart the failed task. If the problem with connectivity between the PA Management Node and the PA Agent was temporary, the task will be processed. If the task fails with a CORBA error after restarting, follow the next steps.
-
Find the hostname and/or IP address of the problem host. This is mentioned in the failed task in the PA Task Manager as the destination host.
-
Make sure the problem host is online:
-
Make sure the host does not experience any performance issues (if the PA task is one that takes a long time to run, its execution time may go beyond the timeout limit on a slow server)
-
Check if the host is connected to network
-
Try to log in to the host’s local console
- Make sure there is enough diskspace on the affected host
-
If the managed server is down, powered off, or stuck, reboot it. Then, once the managed server is online, restart the failed task in PA.
-
Make sure the
pem
service is up and running on the problem host:Linux:
# /etc/init.d/pem status pleskd is running
Windows:
C:UsersAdministrator>net start pem The requested service has already been started.
-
Restart the
pem
service on the managed host:Linux:
# /etc/init.d/pem start Starting pleskd: [ OK ]
Windows:
C:UsersAdministrator>net start pem The PEM service is starting. The PEM service was started successfully.
Restart the failed task in PA.
Important: The managed host will be unavailable for provisioning tasks during a PA Agent restart. This means the host will be unavailable for new service provisioning and for tasks to modify/reconfigure/remove existing customers’ services. Customer services such as websites or mailboxes will not be affected by a PA Agent restart.
Step 6. Make sure that communication ports are open for connections between the PA Management Node and all managed hosts in the PA-managed environment.
Use the telnet utility on the PA Management Node to check that the necessary ports are open (i.e. to check if the PA Management Node can connect to the PA Agent):
telnet 192.0.2.2 8352
Restart the failed task in PA.
Use the tcpdump utility on Linux and the Network Monitor or WireShark utilities on the Windows PA Management Node and/or managed host to find out which port(s) the PA Management Node is trying to connect to when a PA task is running, then open the necessary ports.