[Xorp-users] Config file error

[Rae Harbird]

Dear Bruce

Thanks for your reply. Firstly, I am running XORP on Linux Ubuntu
9.04, kernel 2.6.28-13-generic #45-Ubuntu SMP

Your debugging suggestions were very useful. In answer to your questions:


> * Is runtime linkage for the rubi process OK?
> * Verify this with ldd. It's entirely possible that if you have LD_RUN_PATH
> or LD_LIBRARY_PATH set, or if you are running with shared libraries
> (possibly missing or misdirected), or if there is some other runtime linker
> problem (e.g. 32 bit vs 64 bit thunks) when the executable is invoked.

Yes,  I have checked with as you suggested. The process seems Ok.


>
> * Have you tried writing a shell script wrapper to profile the process
> invocation?
> * Typically I would use this technique for doing valgrind runs for leak
> testing 'in place'.
> * If you look at olsr4.tp in the shipping XORP 1.6 tarball, you'll see a
> commented out reference to such a shell script wrapper.

This was very useful. I tried this and the xorp_rubi process starts
successfully. I can interact with xorp_rubi using the xrls
successfully. Am I right in thinking that when you start the process
independently in this way, the template file is not read? If that is
correct then can you suggest a way of using a minimal / no template
file as a way of continuing to debug this problem?


Rae

2009/7/23 Bruce Simpson <bms at incunabulum.net>:
> Hi,
>
> Sorry for the long delay in my response, I've been tied up with other tasks.
>
> Development questions, which involve walking the code like this can and do
> fall by the wayside; I apologise.
>
> Rae Harbird wrote:
>>
>> Does anyone know what kind of configuration file error might cause this
>> message or give me some hints about how to debug it? Please note: the rubi
>> module depends on olsr which starts up successfully beforehand.
>
> * I'm not too familiar with the Router Manager internals, but I'll give this
> my best shot.
> * I'm going to assume that the XIF was parsed by clnt-gen.py and tgt-gen.py
> OK.
> * The configuration file, and template file, look sane on a first reading.
>
>>
>> [ 2009/07/03 18:03:28  ERROR xorp_rtrmgr:30310 RTRMGR +691
>> master_conf_tree.cc commit_pass2_done ] Commit failed: Can't validate config
>> ready of process rubi
>> [ 2009/07/03 18:03:28  ERROR xorp_rtrmgr:30310 RTRMGR +261
>> master_conf_tree.cc config_done ] Configuration failed: Can't validate
>> config ready of process rubi
>
> Looking at the code, it appears that the error message is triggered in
> rtrmgr/task.cc, Task::step2_3_done().
>
> This callback is invoked in response to _config_validation->validate() in
> that class. I see a bunch of state machines in there, which seem to be there
> to deal with asynchronous process startup, in a fairly generic,
> non-UNIX-specific, way.
>
> The most likely explanation is that the xorp_rubi executable cannot be run.
> To my mind, the error messages in task.cc are obtuse, and difficult to
> understand. If the process can't be run, the Router Manager should be much
> smarter about diagnosis.
>
> Questions:
> * Is runtime linkage for the rubi process OK?
> * Verify this with ldd. It's entirely possible that if you have LD_RUN_PATH
> or LD_LIBRARY_PATH set, or if you are running with shared libraries
> (possibly missing or misdirected), or if there is some other runtime linker
> problem (e.g. 32 bit vs 64 bit thunks) when the executable is invoked.
>
> * Have you tried writing a shell script wrapper to profile the process
> invocation?
> * Typically I would use this technique for doing valgrind runs for leak
> testing 'in place'.
> * If you look at olsr4.tp in the shipping XORP 1.6 tarball, you'll see a
> commented out reference to such a shell script wrapper.
>
> Please let us know what platform you're working with when reporting problems
> like this, it greatly helps us to pin down possible causes.
>
> thanks,
> BMS
>