Skip to contentSkip to conversation

Question about exec_string()

DISCUSSION Erwan Velu 2 participants 4 messages Jul 16, 2013

lore
Share & tools
lore

Erwan Velu

author
#0 lore raw

Hi,

I'm continuing my experiments with fio and adding features to genfio. I'm currently adding to genfio the exec_{pre|post}run support.

I'm benching some ceph and so need to reset OSD's caches with echoing in drop_cache. To achieve that, I'm using kash (from kanif) and having the following syntaxt :

kash -n m1sw1 -n m1sw2 -n m1sw3 -n m2sw1 -n m2sw3 -- echo 3 > /proc/sys/vm/drop_caches

To be able to ssh all this nodes, I need my env to be kept as it relies on my ssh-agent. That's where I do my troubles.

exec_prerun uses exec_string() with does a "sh -c %s'". That does loose my env and prevents me from executing my command.

I've been testing by removing the "sh -c" and only keep "%s" which works perfectly. I'm so wondering what was the targeted role of executing sh instead of running the command directly. If you agree about this change, I can provide the patch.

Note also it would be lovely to have an explicit redirection of the output as unless it's pretty hard to understand if the command got run with its associated output.

Cheers,
Erwan

#1 lore raw
Quoted 17 lines · Erwan Velu

Hi,

I'm continuing my experiments with fio and adding features to genfio. I'm currently adding to genfio the exec_{pre|post}run support.

I'm benching some ceph and so need to reset OSD's caches with echoing in drop_cache.
To achieve that, I'm using kash (from kanif) and having the following syntaxt :

kash -n m1sw1 -n m1sw2 -n m1sw3 -n m2sw1 -n m2sw3 -- echo 3 > /proc/sys/vm/drop_caches

To be able to ssh all this nodes, I need my env to be kept as it relies on my ssh-agent.
That's where I do my troubles.

Quoted 8 lines

exec_prerun uses exec_string() with does a "sh -c %s'". That does loose my env and prevents me from executing my command.

I've been testing by removing the "sh -c" and only keep "%s" which works perfectly.
I'm so wondering what was the targeted role of executing sh instead of running the command directly.
If you agree about this change, I can provide the patch.

I suspect that would be fine.

Quoted 3 lines

Note also it would be lovely to have an explicit redirection of the output as unless it's pretty hard to understand if the command got run with its associated output.

I'll happily take a patch to include the output into the general logging :-). That's the way it should work.

Signature · 1 line
Jens Axboe
author
#2 lore raw
Quoted 3 lines · Jens Axboe

I'll happily take a patch to include the output into the general logging :-). That's the way it should work.

That could be very verbose. Isn't that a problem ?
I though to split it to let user read it later if needed instead of flooding the current console.

#3 lore raw
Quoted 7 lines · Erwan Velu
Quoted 3 lines · Jens Axboe

I'll happily take a patch to include the output into the general logging :-). That's the way it should work.

That could be very verbose. Isn't that a problem ?
I though to split it to let user read it later if needed instead of flooding the current console.

Sure, that'd be fine too. You could have jobname-prerun.txt etc created. I'm fine with either approach.

Signature · 1 line
Jens Axboe