hi Alan
context: on a Fedora Core 3 system (linux 2.6.9) I configured n=5 but FR would not start but one instance. also in the "radiusd -X" there is no notice of thread-pool config being read.
FC4 uses a newer Linux kernel, which *correctly* shows only one process via "ps", even when that process has multiple threads.
ok. you are right. i found the thread info in /proc/$PID/status.
And "-X" means "don't start threads". See the "man" page.
ok, no i meant the daemon mode. sorry, my comment was a bit misleading. it's just that i would expect FR to show every configuration token it has read. and thread pool seems to be ignored in the debug. thanks Alan. ciao artur
Artur Hecker <hecker@enst.fr> wrote:
ok, no i meant the daemon mode. sorry, my comment was a bit misleading. it's just that i would expect FR to show every configuration token it has read. and thread pool seems to be ignored in the debug.
It prints out the configuration it *uses*. It reads pretty much anything from the configuration files. e.g. arthur { france = yes angleterre = no } will be read fine. :) But it won't be printed out in debug mode, because the server isn't looking for it. It makes the server a *lot* more forgiving, and easier to work with. Alan DeKok.
hi Alan
ok, no i meant the daemon mode. sorry, my comment was a bit misleading. it's just that i would expect FR to show every configuration token it has read. and thread pool seems to be ignored in the debug.
It prints out the configuration it *uses*. It reads pretty much anything from the configuration files.
e.g.
arthur { france = yes angleterre = no }
will be read fine. :) But it won't be printed out in debug mode, because the server isn't looking for it.
It makes the server a *lot* more forgiving, and easier to work with.
you know I remember a lot of users having _major_ problems with SCSI because it was too forgiving for simple setups... why not at least mentioning that the server has just ignored a configuration token for whatever reason? e.g. ignoring thread_pool because -X was given at the command line. might help someone to see that his new config is not accepted. and don't you "patches are welcome" on me :-) but anyway, it was not at all my problem. you have already pointed out the actual problem... ciao artur
Artur Hecker <hecker@enst.fr> wrote:
you know I remember a lot of users having _major_ problems with SCSI because it was too forgiving for simple setups...
The server enforces sanity on what it needs. What it doesn't need it ignores.
why not at least mentioning that the server has just ignored a configuration token for whatever reason? e.g. ignoring thread_pool because -X was given at the command line. might help someone to see that his new config is not accepted. and don't you "patches are welcome" on me :-)
Uh... OK. The real answer, though, is that the configuration files are interpreted *after* they're read. So doing what you suggest would mean having the second pass over the configuration files set flags on what was used, and adding a *third* pass that would print out configuration items that weren't flagged on the second one. I'm not sure it's worth it, honestly. Alan DeKok.
participants (2)
-
Alan DeKok -
Artur Hecker