robotology / yarp

YARP - Yet Another Robot Platform

Home Page:http://www.yarp.it

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Yarprun doesn't run command when stdio is specified

IboKhaled opened this issue · comments

As soon as --stdio /<server> is specified, yarprun fails to launch the command.

To Reproduce

  1. Run yarpserver
  2. Run yarprun --server
  3. Start application via yarprun --on /<yarprun-ip:port> --as testing --cmd <app> --stdio /<yarprun-ip:port>

Expected behavior
The application starts and stdio is redirected to a terminal window.

Actual behavior

  • The application isn't running, as can be verified by yarprun --on /<yarprun-ip:port> --ps:
[INFO] |yarp.os.Port|/tmp/port/1| Port /tmp/port/1 active at tcp://192.168.0.164:10003/
[INFO] |yarp.os.impl.PortCoreOutputUnit|/tmp/port/1| Sending output from /tmp/port/1 to /192.168.0.164:10002/ using tcp
[INFO] |yarp.os.impl.PortCoreOutputUnit|/tmp/port/1| Removing output from /tmp/port/1 to /192.168.0.164:10002/
RESPONSE:
=========
  • The xterm window opens and accepts input:
    image
  • Output of the yarprun server:
[INFO] |yarp.os.Port|/192.168.0.164| Port /192.168.0.164 active at tcp://192.168.0.164:10002/
[INFO] Yarprun successfully started on port:  /192.168.0.164
[INFO] |yarp.os.impl.PortCoreInputUnit|/192.168.0.164| Receiving input from /tmp/port/1 to /192.168.0.164 using tcp
STARTED: server=/192.168.0.164 alias=testing cmd=xterm pid=10468
[INFO] |yarp.os.impl.PortCoreInputUnit|/192.168.0.164| Removing input from /tmp/port/1 to /192.168.0.164
  • Output of the yarprun client:
*********** (as testing) (cmd "../camera/build/camera") (on "/192.168.0.164:10002") (stdio "/192.168.0.164:10002") ************
[INFO] |yarp.os.Port|/tmp/port/1| Port /tmp/port/1 active at tcp://192.168.0.164:10003/
[INFO] |yarp.os.impl.PortCoreOutputUnit|/tmp/port/1| Sending output from /tmp/port/1 to /192.168.0.164:10002/ using tcp
[INFO] |yarp.os.impl.PortCoreOutputUnit|/tmp/port/1| Removing output from /tmp/port/1 to /192.168.0.164:10002/
RESPONSE:
=========
10468
STARTED: server=/192.168.0.164 alias=testing cmd=xterm pid=10468

Configuration:

  • OS: Ubuntu 22.04
  • yarp version: 3.7.0 installed from binaries as described in this guide

Notes

  • Without the --stdio-option, the application launches as expected. In the output of yarprun server and client cmd is <app> instead of xterm.
  • Yarprun behaves the same when run from yarpmanager.
  • The yarp server, yarprun server and yarprun client are all running on the same machine.

Am I missing something?

Hi, I managed to reproduce this behaviour in 3.8.0 as well. I also noticed that if you specify a name for the yarprun server

yarprun --server /myServer
yarprun --on /myServer --as testing --cmd <app> --stdio /myServer

the application runs accordingly to yarprun --on /myServer --ps.

Can you confirm that? I am not sure if this is intended behaviour or not but indeed there are checks done on the portname in the code (e.g. see https://github.com/robotology/yarp/blob/master/src/libYARP_run/src/yarp/run/Run.cpp#L1051)

Hi,
thanks for your response!
I was able to confirm your thesis. When specifying the servers name, the application is launched on the target yarprun server.
However the redirection of stdio doesn't seem to work properly regardless.

I tested with a small application that reads an integer from stdin using scanf() and publishes it to a yarp port. When running the application manually from the terminal it works as expected, but when run using yarprun, it publishes 0 all the time, even when nothing was inputted.

Hi @IboKhaled, I reproduced the scenario and indeed it behaves like you described. However, I have tried by reading a string instead of an integer and it seems to be working, can you try that as well?

I am pasting you my sample c++ code:

#include
#include <yarp/os/all.h>
#include <stdio.h>
using namespace yarp::os;

int main(int argc, char *argv[])
{

yarp::os::Network yarp;

yarp::os::BufferedPortyarp::os::Bottle port;
port.open("/test");

while (true)
{
std::string a;
std::cin >> a;

auto &bot = port.prepare();
bot.clear();
bot.addString(a);
port.write();

}

return 0;
}

Is it an acceptable workaround for you? If you only write an integer then I assume you can cast it after reading the string