Bela Log

rph-r

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

giuliomoro

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.

rph-r

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

giuliomoro

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

giuliomoro

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.

rph-r

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...

rph-r

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

giuliomoro

Update to latest dev and that'll work

rph-r

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.

giuliomoro

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.

giuliomoro

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

rph-r

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

giuliomoro

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

rph-r

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.

rph-r

thank you, I will try that asap.

rph-r

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

giuliomoro

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

rph-r

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

giuliomoro

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 ?

rph-r

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

giuliomoro

Right, that's not a fifo, that's because the Bela program starts before the fifo is created.

rph-r The exact code is this one:

Show the service file in /lib/systemd/system/ ?
An easy solution should be to create a file ~~/opt/local/Bela/bela_startup.sh~~ /opt/Bela/local/bela_startup.sh with the following content:

#!/bin/bash

[ -p /tmp/fifo ] || mkfifo /tmp/fifo

[ -z "$BELA_HOME" ] && BELA_HOME=/root/Bela
[ "$ACTIVE" -eq 0 ] && {
        echo "No Bela project set to run on boot" >& 2
        # this should not happen, and if it does, we prevent it from happening
        # again (till the next reboot!)
        make -C "$BELA_HOME" stopstartup
        exit 1
}

if [ "$PROJECT" = "" ]
then
        # run all projects called loop_* in a loop
        ls "$BELA_HOME"/projects/loop_* &>/dev/null &&\
        while sleep 0.1; do
                for PROJECT in "$BELA_HOME"/projects/loop_*; do
                        echo Running $PROJECT;
                        /usr/bin/make -C /root/Bela PROJECT=`basename "${PROJECT}"` CL="${ARGS}" runonly
                done
        done
else
        /usr/bin/make -C "$BELA_HOME" PROJECT="$PROJECT" runonly CL="$ARGS"
fi

and then edit your fifo.sh so that instead of mkfifo /tmp/fifo you have:

[ -p /tmp/fifo ] || mkfifo /tmp/fifo