RAK7249 - System log: daemon.err procd: Failed to execute /tmp/irq2

Issue: No LoRa packages are received by the gateway

Setup:

  • RAK7249 WisGate Edge Max with the latest WisGate02 1.2.1
  • Running on LTE
  • Using the Packet Forwarder mode to send data to private TTS.
  • TTS sees the gateway as online and get updates from the gateway

LoRa® Server: Private The Things Stack server in Azure

Details:
After some troubles with logging in to the gateway using a OpenVPN connection I did a factory reset. then installed FW 1.0.1_RAK which I think is perhaps not a WisGateOS version.

Couldn’t see that any LoRa packages was receive by the gateway, no data showing up in the LoRa Packet Logger.

Looking in the System Log I get spammed by the following messages:

Mon Sep 20 17:43:00 2021 daemon.err procd: Failed to execute /tmp/irq2
Mon Sep 20 17:43:00 2021 daemon.err procd: Failed to execute /tmp/irq2
Mon Sep 20 17:43:00 2021 cron.info crond[2612]: USER root pid 14128 cmd /tmp/run/tty0 > /dev/null 2>&1 &
Mon Sep 20 17:43:00 2021 cron.info crond[2612]: USER root pid 14130 cmd /tmp/irq2 > /dev/null 2>&1 &
Mon Sep 20 17:43:01 2021 daemon.err procd: Failed to execute /tmp/irq2
Mon Sep 20 17:43:01 2021 daemon.err procd: Failed to execute /tmp/irq2
Mon Sep 20 17:43:02 2021 daemon.err procd: Failed to execute /tmp/irq2

I then installed the latest FW WisGateOS 1.2.1 but still the same problem with no LoRa packages coming in and the same messages in System Logs.

What could be the issue with the gateway when behaving like this?

UPDATE 1
I started an SSH session towards the gateway and looked for /tmp/irq2 but can’t find anything like that on the gateway.

Some procd service in /etc/init.d is trying to run a temporary script or tool that would be on the /tmp ramdisk, but isn’t. Why, I have no idea.

if you can get a shell and do grep -lr irq2 /etc/init.d you might at least find out which service it is, but then you’d have to examine that file for hints as to why and if it has anything to do with not receiving packets.

Is the packet forwarder running?

Hi Chris and tnx for your respons.

How can I check if the Packet Forwarder is running? I don’t think I saw anything in the GW UI that indicates if it is running or not but maybe that can be checked in the shell as well.

The grep -lr irq2 /etc/init.d didn’t return anything when I tried this right now.

I found this post: daemon.err procd: Failed to execute /tmp/irq1: No such file or directory · Issue #926 · ericpaulbishop/gargoyle · GitHub where the author ran into a similar problem but on a router and not a gateway. Since it is Linux that is running in both the GW and Router I suppose I guess it’s a similar problem I have.

In this post the author points to two files: /etc/crontabs/root and /etc/inittab and in these files on my gateway I have a pointer to the irq2 that the system log complains about according to:

/etc/crontabs/root
0 0 * * * /usr/bin/rotate_log.sh

          • /tmp/run/tty0 > /dev/null 2>&1 &
          • /tmp/irq2 > /dev/null 2>&1 &

/etc/inittab
::sysinit:/etc/init.d/rcS S boot
::shutdown:/etc/init.d/rcS K shutdown
::askconsole:/bin/login.sh
0:2345:respawn:/tmp/irq2

The author suggest to remove the lines that points to the error message but what would be your suggestion to do. Not even sure how these lines were added since I haven’t seens this system log error message before yesterday.

This sounds like some likely unrelated cron thing.

My guess would be that whatever the problem with receiving packets is, it’s unrelated.

You might start a logread -f on the console serial and collect it in a logging terminal program for a substantial period of time, then go back and look for anything related to the packet forwarder, start_lgw or similar.

I guess you’re using ssh not the serial console, some clients (putty?) can probably log for you or you could do something like this:

ssh user@host "logread -f" | tee logfile

I can never decide if it’s a help or an annoyance but I have logread -f > /dev/console at the end of /etc/rc.local on my openwrt gateways so I can see what’s going on via the serial port from boot, however if I want to do anything else with the serial console I have to killall logread blindly while watching it all flow by. And I’m not actually sure if the stock build has killall…