Might I suggest:


It deals with some of these issues and explains the boundaries of the
problem. As for what a string param can contain, I have no opinion. I only
note that it must handle special characters such as ';', '/', etc. that are
typically found in uri's. I cannot think of any reason it should have a
quote in it.


On 11/8/07 12:25 PM, "Tim Prins" <tpr...@cs.indiana.edu> wrote:

> The alias option you presented does not work. I think we do some weird
> things to find the absolute path for ssh, instead of just issuing the
> command.
> I would spend some time fixing this, but I don't want to do it wrong. We
> could quote all the param values, and change the parser to remove the
> quotes, but this is assuming that a mca param does not contain quotes.
> So I guess there are 2 questions that need to be answered before a fix
> is made:
> 1. What exactly can a string mca param contain? Can it have quotes or
> spaces or?
> 2. Which mca parameters should be forwarded? Should it be just the ones
> from the command line? From the environment? From config files?
> Tim
> Ralph Castain wrote:
>> What changed is that we never passed mca params to the orted before - they
>> always went to the app, but it's the orted that has the issue. There is a
>> bug ticket thread on this subject - I forget the number immediately.
>> Basically, the problem was that we cannot generally pass the local
>> environment to the orteds when we launch them. However, people needed
>> various mca params to get to the orteds to control their behavior. The only
>> way to resolve that problem was to pass the params via the command line,
>> which is what was done.
>> Except for a very few cases, all of our mca params are single values that do
>> not include spaces, so this is not a problem that is causing widespread
>> issues. As I said, I already had to deal with one special case that didn't
>> involve spaces, but did have special characters that required quoting, which
>> identified the larger problem of dealing with quoted strings.
>> I have no objection to a more general fix. Like I said in my note, though,
>> the general fix will take a larger effort. If someone is willing to do so,
>> that is fine with me - I was only offering solutions that would fill the
>> interim time as I haven't heard anyone step up to say they would fix it
>> anytime soon.
>> Please feel free to jump in and volunteer! ;-) I'm willing to put the quotes
>> around things if you will fix the mca cmd line parser to cleanly remove them
>> on the other end.
>> Ralph
>> On 11/7/07 5:50 PM, "Tim Prins" <tpr...@cs.indiana.edu> wrote:
>>> I'm curious what changed to make this a problem. How were we passing mca
>>> param
>>> from the base to the app before, and why did it change?
>>> I think that options 1 & 2 below are no good, since we, in general, allow
>>> string mca params to have spaces (as far as I understand it). So a more
>>> general approach is needed.
>>> Tim
>>> On Wednesday 07 November 2007 10:40:45 am Ralph H Castain wrote:
>>>> Sorry for delay - wasn't ignoring the issue.
>>>> There are several fixes to this problem - ranging in order from least to
>>>> most work:
>>>> 1. just alias "ssh" to be "ssh -Y" and run without setting the mca param.
>>>> It won't affect anything on the backend because the daemon/procs don't use
>>>> ssh.
>>>> 2. include "pls_rsh_agent" in the array of mca params not to be passed to
>>>> the orted in orte/mca/pls/base/pls_base_general_support_fns.c, the
>>>> orte_pls_base_orted_append_basic_args function. This would fix the specific
>>>> problem cited here, but I admit that listing every such param by name would
>>>> get tedious.
>>>> 3. we could easily detect that a "problem" character was in the mca param
>>>> value when we add it to the orted's argv, and then put "" around it. The
>>>> problem, however, is that the mca param parser on the far end doesn't
>>>> remove those "" from the resulting string. At least, I spent over a day
>>>> fighting with a problem only to discover that was happening. Could be an
>>>> error in the way I was doing things, or could be a real characteristic of
>>>> the parser. Anyway, we would have to ensure that the parser removes any
>>>> surrounding "" before passing along the param value or this won't work.
>>>> Ralph
>>>> On 11/5/07 12:10 PM, "Tim Prins" <tpr...@cs.indiana.edu> wrote:
>>>>> Hi,
>>>>> Commit 16364 broke things when using multiword mca param values. For
>>>>> instance:
>>>>> mpirun --debug-daemons -mca orte_debug 1 -mca pls rsh -mca pls_rsh_agent
>>>>> "ssh -Y" xterm
>>>>> Will crash and burn, because the value "ssh -Y" is being stored into the
>>>>> argv orted_cmd_line in orterun.c:1506. This is then added to the launch
>>>>> command for the orted:
>>>>> /usr/bin/ssh -Y odin004  PATH=/san/homedirs/tprins/usr/rsl/bin:$PATH ;
>>>>> export PATH ;
>>>>> LD_LIBRARY_PATH=/san/homedirs/tprins/usr/rsl/lib:$LD_LIBRARY_PATH ;
>>>>> export LD_LIBRARY_PATH ; /san/homedirs/tprins/usr/rsl/bin/orted --debug
>>>>> --debug-daemons --name 0.1 --num_procs 2 --vpid_start 0 --nodename
>>>>> odin004 --universe tpr...@odin.cs.indiana.edu:default-universe-27872
>>>>> --nsreplica
>>>>> "0.0;tcp://;tcp6://2001:18e8:2:240:2e0:81ff:fe2d:21a0
>>>>> :4090 8"
>>>>> --gprreplica
>>>>> "0.0;tcp://;tcp6://2001:18e8:2:240:2e0:81ff:fe2d:21a0
>>>>> :4090 8"
>>>>> -mca orte_debug 1 -mca pls_rsh_agent ssh -Y -mca
>>>>> mca_base_param_file_path
>>>>> /u/tprins/usr/rsl/share/openmpi/amca-param-sets:/san/homedirs/tprins/rsl/
>>>>> examp les
>>>>> -mca mca_base_param_file_path_force /san/homedirs/tprins/rsl/examples
>>>>> Notice that in this command we now have "-mca pls_rsh_agent ssh -Y". So
>>>>> the quotes have been lost, as we die a horrible death.
>>>>> So we need to add the quotes back in somehow, or pass these options
>>>>> differently. I'm not sure what the best way to fix this.
>>>>> Thanks,
>>>>> Tim

Reply via email to