Hi!
any chance to catch the console log? I want to send it further, possibly with pdsend...

The "User Command Line Arguments" box is appended in bash when running the program. So you can put | pdsend 1234 or > /tmp/logfile in there.

6 days later

Ok I've been digging that:
pdsend as single command doesn't work, it need to be a stdin message with a ";" finishing:
echo "bla"\; | pdsend 2500 10.95.133.61
In my case, it would be this line:
| { message=$(</dev/stdin) ; echo $message\; | pdsend 2500 10.95.133.61 ; echo $message ; }
this is to keep the output in the bela terminal.
This line works in the Bela terminal, for example beginning with "date" to have something to output, but doesn't in command line argument box. I get these messages when running:
Running project ...
/bin/sh: 1:
Syntax error: word unexpected
make: *** [runide] Error 2
Makefile:613: recipe for target 'runide' failed
Bela stopped

The latest dev should fix that. However, if you don't want to upgrade, you could just use a fifo and a loop running in a service , e.g.:

mkfifo /tmp/fifo
while true; do
  while read LINE; do
     message="$LINE;";
     echo $message;
     echo $message | pdsend 2500 10.95.133.61;
  done < /tmp/fifo;
  # pipe will get EOF when the writer exits, so we put it in a loop
  sleep 0.1;
done

Then you can simply > /tmp/fifo in the user options of the program

    10 days later

    that is working!!
    however I don't have the log in the Bela IDE console anymore. I only can see it with
    journalctl -fu sendlog
    I can live with that but if you have a quick solution...

    giuliomoro Then you can simply > /tmp/fifo in the user options of the program

    This removes it from the IDE's log (which is journactl -fu bela_startup). You could try | tee /tmp/fifo instead of > /tmp/fifo and that should give you both.

      I get this error on launch, then Bela stops:
      tee: invalid option -- 'X'

      2 months later

      Hi!
      maybe you can help me with that:
      since some days for any reason the script above send continuously the lines. Even if I comment the pdsend line, even if Bela is stopped, even if I comment > /tmp/fifo in user command line argument, and even if I empty /tmp/fifo (echo ' ' > /tmp/fifo), it sends continuously empty lines...
      any idea? I don't remember to have tweaked anything in this area.

        Can you describe exactly your cureent setup? Above we've gone through several iterations and I am not sure where you ended up

        • Rrph-r

          • Post #11

          oh, could it be a conflict with auto-run project on boot?

          It could be, but you need to describe your system in detail if you need any further insights.

          Bela sends logs to a remote computer with the script above as a service, through the > /tmp/fifo command. Tell me what else you need to know.

          5 days later

          rph-r since some days for any reason the script above send continuously the lines. Even if I comment the pdsend line, even if Bela is stopped, even if I comment > /tmp/fifo in user command line argument, and even if I empty /tmp/fifo (echo ' ' > /tmp/fifo), it sends continuously empty lines...

          If a program has /tmp/fifo continuously open, you can track it down with lsof /tmp/fifo. If lsof is not installed and you cannot install it, try ls -l /proc/*/fd | grep -B10 tmp/fifo instead. You'll get something like this:

          lrwx------ 1 root root 64 Feb 12 22:57 4 -> socket:[6869]
lrwx------ 1 root root 64 Feb 12 22:57 5 -> socket:[6970]
lrwx------ 1 root root 64 Feb 12 22:57 6 -> socket:[7908]
lrwx------ 1 root root 64 Feb 12 22:57 7 -> socket:[8045]
l-wx------ 1 root root 64 Feb 12 22:57 8 -> /run/systemd/sessions/1.ref
lrwx------ 1 root root 64 Feb 12 22:57 9 -> /dev/ptmx

/proc/524/fd:
total 0
lrwx------ 1 debian debian 64 Feb 12 22:55 0 -> /dev/pts/0
l-wx------ 1 debian debian 64 Feb 12 22:55 1 -> /tmp/fifo
--
/proc/533/fd:
total 0
lrwx------ 1 debian debian 64 Feb 12 22:55 0 -> /dev/pts/1
lrwx------ 1 debian debian 64 Feb 12 22:55 1 -> /dev/pts/1
lrwx------ 1 debian debian 64 Feb 12 22:55 2 -> /dev/pts/1
lrwx------ 1 debian debian 64 Feb 12 22:55 255 -> /dev/pts/1

/proc/5353/fd:
total 0
lrwx------ 1 debian debian 64 Feb 12 22:58 0 -> /dev/pts/0
l-wx------ 1 debian debian 64 Feb 12 22:58 1 -> /tmp/fifo
--

/proc/79/fd:
total 0

/proc/7/fd:
total 0

/proc/800/fd:
total 0
lrwx------ 1 debian debian 64 Feb 12 22:55 0 -> /dev/pts/5
l-wx------ 1 debian debian 64 Feb 12 22:55 1 -> /tmp/fifo

          Look at the /proc/<pid>/fd: entries before each /tmp/fifo occurrence and you'll see the <pid> of the culprit process. Then ps aux -q <pid> will tell you more information about the process.

            thank you, I will try that asap.

            18 days later

            • Rrph-r

              • Post #16
              • Edited

              I installed everything on another Bela for testing (the other is in place in the installation). I could reproduce the issue. Here is the output:

              root@bela:~# ls -l /proc/*/fd | grep -B10 tmp/fifo
ls: cannot access '/proc/20344/fd': No such file or directory
lrwx------ 1 root root 64 Mar  3 14:03 1 -> /dev/ttyGS0
lrwx------ 1 root root 64 Mar  3 14:03 2 -> /dev/ttyGS0
lr-x------ 1 root root 64 Mar  3 14:03 3 -> /etc/issue

/proc/4/fd:
total 0

/proc/414/fd:
total 0
lr-x------ 1 root root 64 Mar  3 14:07 0 -> /dev/null
l-wx------ 1 root root 64 Mar  3 14:07 1 -> /tmp/fifo
lrwx------ 1 root root 64 Mar  3 14:07 10 -> socket:[17983]
lrwx------ 1 root root 64 Mar  3 14:07 2 -> socket:[17983]

/proc/418/fd:
total 0
lr-x------ 1 root root 64 Mar  3 14:07 0 -> /dev/null
l-wx------ 1 root root 64 Mar  3 14:07 1 -> /tmp/fifo
--
lrwx------ 1 root root 64 Mar  3 14:07 44 -> /dev/rtdm/rtdm_pruss_irq_0
lrwx------ 1 root root 64 Mar  3 14:07 45 -> /dev/rtdm/rtdm_pruss_irq_0
lrwx------ 1 root root 64 Mar  3 14:07 5 -> /dev/i2c-2
lrwx------ 1 root root 64 Mar  3 14:07 6 -> /dev/i2c-2
lrwx------ 1 root root 64 Mar  3 14:07 7 -> /dev/i2c-2
lrwx------ 1 root root 64 Mar  3 14:07 8 -> /dev/mem
lrwx------ 1 root root 64 Mar  3 14:07 9 -> /dev/i2c-2

/proc/490/fd:
total 0
lr-x------ 1 root root 64 Nov  3  2016 0 -> /tmp/fifo
root@bela:~# ps aux -q 414
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root       414  0.0  0.2   1516  1120 ?        S    14:01   0:00 /bin/sh -c sync& cd /root/Bela/projects/CommunityEchoTesting && /root/Bela/projects/CommunityEchoTesting/CommunityEchoTesting -p512 -C4 -B16 -N1 -G0 -M0 -H0,-6 -H1,-6 -H2,-6 -H3,-6 -H4,-6 -H5,-6 -H6,-6 -H7,-6 -I0,0 -I1
root        17  0.0  0.0      0     0 ?        SN   14:01   0:00 [ksmd]
root@bela:~# ps aux -q 418
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root       418  6.6  5.5  31848 27776 ?        SLl  14:01   0:34 /root/Bela/projects/CommunityEchoTesting/CommunityEchoTesting -p512 -C4 -B16 -N1 -G0 -M0 -H0,-6 -H1,-6 -H2,-6 -H3,-6 -H4,-6 -H5,-6 -H6,-6 -H7,-6 -I0,0 -I1,0 -I2,10 -I3,10 -I4,10 -I5,10 -I6,10 -I7,10 -X0 -Z0,1,2,3
root        17  0.0  0.0      0     0 ?        SN   14:01   0:00 [ksmd]
root@bela:~# ps aux -q 490
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root       490  7.9  0.2   1428  1000 ?        Ss   14:01   0:43 /bin/sh /root/Bela/projects/CommunityEchoTesting/fifo.sh
root        17  0.0  0.0      0     0 ?        SN   14:01   0:00 [ksmd]

              I confirm this happens when autorun is enabled

              Look at the /proc/<pid>/fd: entries before each /tmp/fifo occurrence and you'll see the <pid> of the culprit process. Then ps aux -q <pid> will tell you more information about the process.

              So in the example above you'd need to do

              ps aux -q 414

              To see what process is accessing /tmp/fifo

              yes, the results are bellow the ls command return, actually there are 3 processes using /tmp/fifo, right?

              Is /root/Bela/projects/CommunityEchoTesting/fifo.sh the file that runs as a service and reads from /tmp/fifo ?

              Does this issue happen occasionally or always? If it's intermittent, I am wondering whether it's because the Bela project starts writing to /tmp/fifo before fifo.sh created it as a fifo, although I cannot reproduce the behaviour when I try to simulate that situation. What does the service file look like?
              When this issue happens, what do you get from ls -l /tmp/fifo ?

              It happen always and permanently when autorun is enabled, never otherwise.
              and yes, fifo.sh is the file that write to /tmp/fifo. The code is the suggestion you wrote above. The exact code is this one:

              #!/bin/sh

mkfifo /tmp/fifo

while true ; do
  while read LINE; do
    message="$LINE;";
    echo $message ;
    echo $message | pdsend 2500 10.95.133.61;
  done < /tmp/fifo;
  # pipe will get EOF when the writer exits, so we put it in a loop
  sleep 0.1;
done