[Xorp-users] Config file error

[Bruce Simpson]

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