I did increase the logging level to Maximum as per your suggestion and most detail seems to be in the messages log file under \var\log\messages. Looking at the failed and success scenarios in the log file doesn’t elicit any new information as to why the custom app doesn’t come up on a quick power cycle and more over the APP-MANAGER indicates success in both scenarios as per the log file.

Should I be looking at any other log files for better information?

Just fyi, I do use the /sbin/angel application to load the nodejs custom app I have built, could this be causing any issues? Although I have renamed it/created a soft link appropriately so that it doesn’t clash with the node-red’s use of the same application.

Are there are any hardware differences between the ATT model and the Verizon conduit AEP models?

Thanks,
Ajay

Hi Jeff,

I do provide the PID and status information via status.json. But I don’t think the application didn’t even run to begin with. At the least the <app-name>.log file should have been created as the o/p of the console is piped to a log file and moreover I have Winston logging as well and handle the “ExitOnError” event as well. So as far as I can see the application never runs. Mostly I am worried about the difference in behavior of the exact same application working differently on two different conduits.

Also as an experiment, I removed the /sbin/angel from launching the nodejs app, instead launched it directly using the node application and still fails loading the app, under under 30 seconds power cycle.

If you would rather prefer I rather open a ticket, let me know I can attach the log files for review and the application tar file so the issue can be reproduced?

Thanks,
Ajay

Thanks Jeff, I never thought of that possibility. Is there a way to figure out what the run level was, when it was booted up?

Also I have another update, I could reproduce it consistently on the ATT based AEP conduit now. However I removed the /sbin/angel dependency from my startup scripts, I just use the following

My environment variables in my start scripts.

NAME="TestLoraUplinkPktManager"
APP_LOGDIR="/var/log/app"

# Use MultiTech Provided $APP_DIR environment variable
DAEMON="/usr/bin/node"
DAEMON_ARGS="$APP_DIR/app.js > $APP_LOGDIR/$NAME.log 2>&1"

RUN_DIR=$APP_DIR

START_STOP_DAEMON="/usr/sbin/start-stop-daemon"
PID_FILE="/var/run/$NAME.pid"

My start script for my app. Let me know if you see any concerns with the start script.

$START_STOP_DAEMON --start --background --pidfile "$PID_FILE" --make-pidfile --chdir "$RUN_DIR" --startas /bin/bash -- -c "exec $DAEMON $DAEMON_ARGS"

Even though the application hasn’t started the app-manager believes the application has started successfully, even though there is no app running with that PID as stored in the pid file.

Thanks,
Ajay

Hi Jeff,

Where does the start-stop-daemon typically look for the pid file?

Thanks,
Ajay.

I actually saw the run level mentioned in the boot logs and it mentioned Runlevel 5, so the application should technically run.

I also could confirm my startup scripts are being called as I have added log statements using the logger object in my Applications Start Scripts.

Here is one thing I have noticed, when I have the /sbin/angel loading my app, the angel application loads up fine, however the node application or rather my custom app is not run. Could this be an memory issue?

In the node-red startup in app.py i see the following lines, is this setting some kind of memory cap on the node-red app?

/usr/bin/node --max-old-space-size=40 /opt/node-red/red.js

if so, should I be limiting the memory usage on my custom app as well and would the same number applied to node-red suffice for my app as well?

Thanks,
Ajay

Adding that switch to manage the memory didn’t help either.

Its almost like whenever it fails, one of the things I have noticed is that the /var/log/app folder takes a little while to be created. I am going to try and see if write my log file to a different location does it help.

Thanks,
Ajay