Tutorial: Installing Startup Scripts on NI Linux Real-Time

[jrobalin]

Sample Startup Script

[jamie_mac]

Thanks jrobalin for a great tutorial. I've been trying to get C application to start on system reboot for the past day or so  and this was a real help. However I'm still stuck on a few points which might be useful for other relative newcomers to this:

1) I have followed your tutorial, installed the script and got a program to start by calling

/etc/init.d/criodaq start (criodaq is the name of the script and cRioTestC is a C binary). I know the program starts because I have programmed LEDs on the chasis but nothing prints in the console. Is there a way in the script to either log print statements from the program running or show in console?

2) I can find my progam in the rc1.d,rc2.d,rc3.d,rc4.d,rc5.d and rc6.d but the program does not start on a system reboot- at least the LED's which are supposed to turn on do not . Any ideas on how I can begin to troubleshoot this?

Script below

#!/bin/bash

NAME="cRioTest application"

DAEMON=/home/admin/cRioKE/cRioTestC

ARGS="1"

USER=admin

PIDFILE=/var/run/cRioTestC.pid

do_start() {

    /sbin/start-stop-daemon --start --pidfile $PIDFILE \

        --make-pidfile --background \

        --chuid $USER --exec $DAEMON $ARGS

}

do_stop() {

    /sbin/start-stop-daemon --stop --pidfile $PIDFILE --verbose

}

case "$1" in

  start)

    echo "Starting $NAME"

    do_start

    ;;

  stop)

    echo "Stopping $NAME"

    do_stop

    ;;

  restart)

    echo "Restarting $NAME"

    do_stop

    do_start

    ;;

  *)

    echo "Usage: $0 {start|stop|restart}"

    exit 1

    ;;

esac

exit 0

[BradM]

jamie_mac,

I'm glad you were able to find this tutorial helpful.

jamie_mac wrote:

...

Is there a way in the script to either log print statements from the program running or show in console?

...

                   

A cheap, easy way to log output from a program that is being launched as a daemon would be to instead call a wrapper script and execute the actual program with something like

/home/admin/cRioKE/cRioTestC &> /tmp/cRioTestC.log

This is cheap, dirty, but gets the job done.

A more correct, clean way to do this would be to use the syslog() functionality to log to the system logger daemon. Depending on how you open the syslog connection, the messages will likely show up in /var/log/messages, so long as you open the connection with defaults (e.g. don't try to open the connection with the LOG_AUTH facility).

jamie_mac continues:

...

2) I can find my progam in the rc1.d,rc2.d,rc3.d,rc4.d,rc5.d and rc6.d but the program does not start on a system reboot- at least the LED's which are supposed to turn on do not . Any ideas on how I can begin to troubleshoot this?

...

                   

Getting some semblance of logging working will go a long way in helping you troubleshoot, but for the time being let's do a sanity check. Can you check to see if the process is running by checking the output of ps -e | grep cRio? How did you install the rc.N links? update-rc.d? What actual command did you use?

[jamie_mac]

Thanks for the reply Brad

So the way I solved this was to set the program to start after everything else. Seems like /usr/sbin/update-rc.d -f Name defaults sets the application loading somewhere in the middle of other daemons? To set the application to load right at the end of everything else I used.

/usr/sbin/update-rc.d -f Name defaults 99 0. That got the thing starting when the cRio loads

To log files I had to remove --background from my script and add > /home/admin/cRioKE/criodaqlog.log 2>&1 Code below. I realise this is a 1) a bit dirty and 2) I don't fully understand what the consequences of removing --background might be?

Cheers

Jamie

#!/bin/bash

NAME="crioWhaleDAQ application"

DAEMON=/home/admin/cRioKE//cRioTestC

ARGS="0";

USER=admin

PIDFILE=/var/run/cRioTestC.pid

do_start() {

    /sbin/start-stop-daemon --start --pidfile $PIDFILE \

        --make-pidfile \ #--background \

        --chuid $USER --exec $DAEMON $ARGS > /home/admin/cRioKE/criodaqlog.log 2>&1

}

...rest same as tutorial.

[jamie_mac]

PS. For anyone confused about this update-rc.d boot order stuff this is a good link.

[BradM]

Yes, jamie_mac, omitting the actual dependecy-resolution numbers places the links such that your daemon is started and stopped at 20. It is likely that there is some dependent daemon or service that is not yet available when it was starting at the default level. The actual LED facility is provided by the kernel, so it was likely some other resource that was unavailable

[kwkengineer]

Brad - Should I expect the cheap and dirty redirection you mentioned above work when running the binary from a call to System Exec.vi from LabVIEW?

The log file gets created, but no output appears in the file.  When I use the same redirection from the command line, I get a file and the output.

Kevin

[BradM]

The SystemExec VI is a bit of a special case, it basically does things to hijack the standard output. You can probably get around this by adding a layer: have a script that, within the script, will call the binary and redirect stdout to a log file. Not 100% sure this will work, but I know that trying to take stdout from the System Exec.vi is unlikely to do what you want

[Drew_T]

I'm not sure if anyone still monitors this page, but I am running into a conundrum here and I was wondering if someone had insight.  My app requires remote access to the serial ports on my cRIO from the host, so I have configured ser2net (successfully) to forward them over TCP/IP.  Using this tutorial as a guide, I was able to get ser2net to start on boot, which is fantastic. 

The only issue I am having is trying to configure the serial port settings at boot.  This is a slightly different use case from the above, since I don't want to start a daemon, but simply run a few commands.  I use stty to set my serial configurations, and have incorporated it into the startup script as shown below.

#!/bin/bash

NAME="Ser2Net Daemon"

DAEMON=/usr/sbin/ser2net

ARGS=" -n"

USER=admin

PIDFILE=/var/run/ser2net.pid

do_start() {

    /sbin/start-stop-daemon --start --pidfile $PIDFILE \

        --make-pidfile --background \

        --chuid $USER --exec $DAEMON -- $ARGS

}

do_stop() {

/sbin/start-stop-daemon --stop --pidfile $PIDFILE --verbose

}

case "$1" in

  start)

echo "Starting $NAME"

/bin/stty -F /dev/ttyNIRIOslot2port0 115200 ixon

/bin/stty -F /dev/ttyNIRIOslot2port1 115200 ixon

do_start

;;

  stop)

echo "Stopping $NAME"

do_stop

;;

  restart)

echo "Restarting $NAME"

do_stop

do_start

;;

  *)

echo "Usage: $0 {start|stop|restart}"

exit 1

;;

esac

exit 0

Now, if I test this after installing the script (by entering "/etc/init.d/ser2net.startup start" in the shell), this works fine.  However, if I reboot, the commands seem to do nothing, and the port config stays default.

Does anyone have any ideas why these commands would fail during startup but not during normal operation?  Is there a way to debug what is happening on startup?

Thanks in advance!

Drew

[ScotSalmon]

Replied to your separate post here: https://forums.ni.com/t5/NI-Linux-Real-Time-Discussions/Setting-Serial-Port-Configuration-on-Startup...

[RVallieu]

This sounds like what I need to do in order to satisfy a requirement I have for an upload process where we are loading new RTEXE onto the system not using the project, I need a way to launch the newly uploaded RTEXE and then if it fails to revert to the original RTEXE which will only be replaced once the new RTEXE starts successfully.

[SeaSick]

While working with another user to follow this tutorial, the user was receiving errors because their Windows formatting of the file wasn't recognized by the Linux system. They were able to resolve this by following the guidance here. Once the text file was converted to a format that was readable by the Linux OS they were able to successfully follow this tutorial.

I just wanted to post this resource/troubleshooting step here in case others experience similar problems in the future!