CALLS TO R/W PROCESS IMAGE CAUSE SILENT PROGRAM CRASH IF LAUNCHED AT BOOT BY INIT.D

Topics about the Software of Revolution Pi
Post Reply
GriPi
Posts: 1
Joined: 16 May 2017, 22:50
Answers: 0

CALLS TO R/W PROCESS IMAGE CAUSE SILENT PROGRAM CRASH IF LAUNCHED AT BOOT BY INIT.D

Post by GriPi »

Hi,

a strange behaviour when running a program that accesses process image, only when launched automatically by init.d

Symptoms
Automatically launching a program at boot (before login), it crashes silently but the process still seems to be loaded in memory.

Cause
It seems that the RevPi process image interface (reading/writing process image) doesn’t work when the program is launched automatically before login (inti.d method).
If the program is launched manually from console all works fine.

In fact, remarking calls to process image all works fine.


Note

  • Access to process image has been done as in the sample program that can be found on RevPI GitHub site (derived from piControlIf.c ).
    The process image is accessed from a thread.

Script code (unable to attach file)

#! /bin/sh
### BEGIN INIT INFO
# Provides: WebApp
# Required-Start:
# Required-Stop:
# Should-Start:
# X-Start-Before:
# Default-Start: 2
# Default-Stop:
# X-Interactive: true
# Short-Description: Starts WebApp daemon
# Description: Starts WebApp daemon.
### END INIT INFO

# inserire qui il path dove risiede WebApp se necessario
WebApp_DIR=/data/webhmi
# settare a 1 per abilitare il core dump; il file di trace è invece sempre generato
# COREDUMP_ENABLE=1
WebAppStart()
{
# verifica se WebApp e' già in esecuzione, e' richiesto il comando pidof !
if pidof WebApp ; then
echo "WebApp already running !"
exit 1
fi

if test "$COREDUMP_ENABLE" = "1" ; then
echo core_%e_%t > /proc/sys/kernel/core_pattern
ulimit -c unlimited
fi
cd /data/webhmi
nohup ./WebApp &
#./WebApp -daemon &
}

WaitProcessEnd()
{
cnt=0
while test -e /proc/$1 -a $cnt -lt $2 ; do
sleep 1
cnt=$((cnt + 1))
done
! test -e /proc/$1
}

WebAppStop()
{
timeout=15
# ricava il PID di WebApp, e' richiesto il comando pidof !
pid=`pidof WebApp`
if test -z $pid ; then
echo "WebApp not running !"
exit 1
fi

# tentativo di arresto con SIGTERM (arresto soft)
kill $pid

if ! WaitProcessEnd $pid $timeout ; then
# arresto soft non riuscito, tenta con SIGQUIT (arresto forzato, gestito dal signal handler)
echo "Failed to stop gracefully with SIGTERM, sending SIGQUIT ..."
kill -QUIT $pid
if ! WaitProcessEnd $pid $timeout ; then
# anche l'arresto con SIGQUIT e' fallito, manda il SIGKILL, che deve terminarlo per forza (salvo blocco nel kernel)
echo "Failed to stop with SIGQUIT, sending SIGKILL ..."
kill -KILL $pid
if ! WaitProcessEnd $pid $timeout ; then
# neanche SIGKILL ha funzionato: il processo e' bloccato nel kernel
echo "Failed to stop with SIGKILL !!! Can not stop WebApp"
fi
fi
fi
}

DESC="WebApp PLC Runtime"

case "$1" in
start)
echo -n "Starting $DESC: "
WebAppStart
echo "done."
;;
stop)
echo -n "Stopping $DESC: "
WebAppStop
echo "done."
;;
restart)
echo -n "Restarting $DESC: "
WebAppStop
sleep 1
WebAppStart
echo "done."
;;
*)
echo "Usage: WebApp {start|stop|restart}" >&2
exit 1
;;
esac
exit 0




The program works fine if manually launched by means of:
/etc/init.d/WebAppDaemon start
Or
./data/webmi/webApp
User avatar
volker
Posts: 1046
Joined: 09 Nov 2016, 15:41
Answers: 1

Re: CALLS TO R/W PROCESS IMAGE CAUSE SILENT PROGRAM CRASH IF LAUNCHED AT BOOT BY INIT.D

Post by volker »

Generally we can only say that many users do use the PiControl calls from applications which have been auto started at boot time. So it seems to be very unlikly that your application sw suffers from a PiControl bug.
I'm trying to do my best to analyze your problem but generally we can't debug customers application as a support service. Please have patience for suggestions from the community and our sw team as soon as the team has finished the actual releasing process for our new image.
Without analyzing your code but only on the assumptions that an app which is generally running when started under different conditions my first suggestion is that your app may suffer from missing rights when started automatically ore does not have access system paths which you do can access when starting manually. So please try thinking that way and analyze your app if there are any parts which do not run when a path can't be reached or rights are missing etc.
You should also carefully avoid any uncontrolled abortion of the program by using try clauses as many as possible and use exceptions to find out the specific point of program abortion. Also check log files for any entries which may give you the line of program abortion.
But these thing are nothing new to professional programmers so I may tell you stuff you already know well. Nevertheless; If I would have to debug the app I would go exactly this way. Only if you know the line of abortion you will be able to find the cause of the abortion...
Good luck!
Unser RevPi Motto: Don't just claim it - make it!
Post Reply