dw-start.sh script isseu

[PD0RBO]

Just putting it out there, I'm a novice regarding Linux at configuring level.

I've got Direwolf and RTL-SDR running on a Orange Pi Zero and ARMbian.

Running the .sh is giving me:
$ ./dw-start.sh
Direwolf in CLI mode start up
There is a screen on:
3727.direwolf (05/14/2017 07:17:06 PM) (Detached)
1 Socket in /var/run/screen/S-usr.

$

Direwolf and rtl_fm don't seem to be running from there.

In the script I already changed 'screen -d -m -S' into '-dmS'

Making a detached screen and running rtl_fm and direwolf from there works just fine.

[dranch]

Hello PD0RBO,
Are you reporting a problem? These Github "issues" are for reporting bugs or enhancement requests. If you want general support, please join the direwolf_packet@yahoogroups.com Yahoo group. Back to this specific Github issue, it seems things are working ok for you as the above message means that there is already a direwolf instance running. If you would like to attach to that running screen session, run the command:

screen -dr direwolf

Unless you'd like to report an issue, please close this "issue" and if you want more help, join the Yahoo group.

--David
KI6ZHD

[PD0RBO]

I'd really like to report a problem.

:~$ screen -ls
No Sockets found in /var/run/screen/S-usr.

:$ cd direwolf
:/direwolf$ ./dw-start.sh�
Direwolf in CLI mode start up
There is a screen on:
495.direwolf (05/15/2017 03:20:03 PM) (Detached)
1 Socket in /var/run/screen/S-usr.

:~/direwolf$ screen -ls
No Sockets found in /var/run/screen/S-usr.

:/direwolf$ screen -dr direwolf
There is no screen to be detached matching direwolf.
:/direwolf$

[dranch]

Try these commands and see if you get a different result:

sudo screen -ls
ps ax | grep screen

If those commands find a running screen session, this means you're aren't running screen under the correct user to see the session.

--David
KI6ZHD

[PD0RBO]

/direwolf$ ./dw-start.sh
Direwolf in CLI mode start up
There is a screen on:
5711.direwolf (05/15/2017 07:04:00 PM) (Detached)
1 Socket in /var/run/screen/S-usr.

/direwolf$ sudo screen -ls
[sudo] password for usr:
No Sockets found in /var/run/screen/S-root.

/direwolf$ ps ax | grep screen
5736 pts/0 S+ 0:00 grep --color=auto screen
/direwolf$

Remi de PD0RBO

[dranch]

It's strange that it's saying "S-usr" which makes me think that this screen is running on a non-existent username "usr". Since it seems Direwolf isn't running, you probably have some stale lock files in /var/run/screen/ . To confirm, try running:

sudo find /var/run/screen

I would recommend to cd into that directory and delete all directories and files in there. For example, use:

sudo rm -Rf /var/run/screen/S-usr

Clear out anything else in there as well (they are just temporary lock files). Once done, I'd just recommend to reboot your Rpi to have a clean slate and then try again.

[PD0RBO]

I substituted the username for 'usr'

Deleting the directories and files worked once, I added the line in the cron and rebooted.

Then the same problem occured, deleting the line in the cron and deleting the files and directory again didn't work from there.

I backstepped my tracks a couple of times to check if I stepped over something I did before, but didn't now.

That being said, I experience this problem on a fresh and clean install.

[dranch]

Ok, so you cleared out old directory and file state from /var/run/screen and then rebooted? At that point, Direwolf started up ok? After that, did direwolf stop working for you or did you again reboot the Rpi somehow? If a reboot.. HOW did you reboot it (pulling the power plug is VERY VERY bad for an Rpi). It's critical that you gracefully shutdown the Rpi every time. To help further your troubleshooting, I would recommend to disable the dw-start.sh script from the crontab for now and load it via the /etc/rc.local file. This should load Direwolf only once but also not keep trying to restart it just to help troubleshooting.

[PD0RBO]

I have some experience with SD cards, electronics and microcontrollers. What makes me to reboot and not powercycle.

The only time it worked I just empty the directory like you sugested and rebooted, then ran the .sh from direwolf$ and it worked.

Then I added the crontab line like in the documentation and rebooted.

Then checked the running processes with 'top' and discovered that Direwolf and rtl_fm werent running.

Removed the line of the crontab and began troubleschooting by repeating the above sugested steps.

[dranch]

So it seems that after adding the dw-start.sh to the crontab and rebooting then created the issue? This is very strange as when you reboot a machine, all processes should be shutdown. If screen is shutdown first, direwolf should also be shutdown as part of that process and all screen lock files should be auto-cleaned up automatically.

[PD0RBO]

Well, focussing on the 'once'. Yes, adding the crontab did created the isssu on that particular instance. However! I wasn't able to replicate that particular hapening and got stuck with the isseu like I experienced before what made me report this problem. Do you have experience with Orange PI zero and ARMBian (Ubuntu stable)? Maybe you can sugest a distro I can use what had been proven to work an troubleshoot from there?

…

Op 17 mei 2017 om 17:48 heeft David Ranch ***@***.***> het volgende geschreven: So it seems that after adding the dw-start.sh to the crontab and rebooting then created the issue? This is very strange as when you reboot a machine, all processes should be shutdown. If screen is shutdown first, direwolf should also be shutdown as part of that process and all screen lock files should be auto-cleaned up automatically. — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[dranch]

Well, try to reproduce the issue and maybe we can mitigate it. Beyond that, no, I don't have any experience on the OrangePi but if it's running Ubuntu reliably, it should just work.

[KG4Y]

I was able to get around this problem by modifying the script. I changed the line where screen is actually called, because I thought the shell might be interpreting the meaning of the pipe in the string in an unexpected way when it is passed as a variable. So, I replaced this line:

$SCREEN -d -m -S $DWCMD >> $LOGFILE

with this:

$SCREEN -dmS direwolf /bin/bash -c '/usr/local/bin/rtl_fm -f 144.39 M - | /usr/local/bin/direwolf -c /home/kg4y/sdr.conf -r 24000 -D 1 - ' >> $LOGFILE

After that, the cron job started to work, and the screens are detached in daemon mode, leaving the rlt_rm and direwolf processes running.

For what it's worth, I also modified the cron frequency to every five minutes to reduce the noise in the log file:

*/5 * * * * /home/kg4y/dw-start.sh >> /home/kg4y/dw.log 2>&1

This second log from cron only lists output when the dw-start.sh script actually starts the processes. Regular time stamps continue in /var/tmp/dw-start.log

I hope that helps!

Best 73,

Mike - KG4Y

[pe2kdk]

Dear @PD0RBO,

I walked into the same trap, the dw-start script does a check in the process list to see if Direwolf is already running. If 'direwolf' is the or part of the hostname, the script 'thinks' it has found a running Direwolf process which is actually the avahi-daemon. Just change your hostname without 'direwolf' of modify the script by using the $DIREWORF define:

original:
a=ps ax | grep direwolf | grep -vi -e bash -e screen -e grep | awk '{print $1}'

suggestion:
a=ps ax | grep $DIREWOLF | grep -vi -e bash -e screen -e grep | awk '{print $1}'

Note. do not copy past the sample code, due to the styling of this forum the required quotes are not shown correctly.

By this small change the hostname doesn't matter anymore, the script checks the correct process.

All the best, 73,
Karel - PE2KDK

[PD0RBO]

Hi All,

I tried Mike - KG4Y sugestion and it worked. I did tried Karel - PE2KDK sugestion, however I missed being $DIREWOLF in caps and it didn't work. I didn't tried again with caps.

I have now a working situation.

Thanks for thinking for me.

73

Remi

[dirkbeer]

I had the same problem on a Raspberry Pi. Another solution is to replace

DWCMD="bash -c 'rtl_fm -f 144.39M - | direwolf -c sdr.conf -r 24000 -D 1 -'"

with a function:

dwcmd() { bash -c 'rtl_fm -f 144.39M - | direwolf -c sdr.conf -r 24000 -D 1 -'; }

and to replace

$SCREEN -d -m -S direwolf $DWCMD >> $LOGFILE

with

$SCREEN -d -m -S direwolf $(dwcmd) >> $LOGFILE

This is the better/safer way to implement things according to https://stackoverflow.com/questions/43752854/bash-pipe-character-in-variable-for-command-substitution

KX3F

[dranch]

A new version of this script (intended for RTL SDR users) but has several other improvements that may help standard sound device Direwolf use cases) is offered here: https://groups.io/g/direwolf/message/8002