Page History

8. How do I start my IOC? Where is my ioc's statrup.cmd?

There are a few scripts that automate this process.

To begin with, there is the 'ipxe.ini' script in the tftp boot area /afs/slac/g/lcls/tftpboot/linuxRT/boot that PXE will run.

This is where the version of (linuxRT) kernel to run is specified as follows:

set vers 3.2.13-121108

This version number can be over-ridden by a chained, host-specific pxe init script to load an image different from the above:

chain ${hostname}.ipxe ||

For example, we have defined a script specifically for our ioc ioc-b34-bd32.ipxe which chooses to load the latest linuxRT image:

set vers 3.14.12-rt9

This is also the place to over-ride the 'root-path' option specified in the DHCP configuration file dhcpd.conf.

For example, I may decide to over-ride the afsnfs1 server and instead choose to get my boot image from afsnfs2 server:

set extra-args ROOTPATH=afsnfs2:/afs/slac:/afs/slac BOOTFILE=/afs/slac/g/lcls/epics/iocCommon/ioc-b34-bd32/startup.cmd

A few more extra arguments are specified in ioc-b34-bd32. Leave them as they are.

The 'ipxe.ini' script loads the linuxRT kernel via the TFTP protocol:

kernel --name linux tftp://${next-server}/linuxRT/boot/${vers}/bzImage && initrd tftp://${next-server}/linuxRT/boot/${vers}/rootfs.ext2 || shell
imgargs linux debug idle=halt root=/dev/ram0 console=ttyS0,115200 BOOTIF_MAC=${net0/mac:hex} ${extra-args} || boot || shell

After linuxRT boot image is downloaded to the target and linuxRT starts to run, additional nfs mounts will be done.

The afs to nfs translator service makes available the directory structure, to all clients that have mounted this nfs space.
NFS File Servers for LCLSDEV are afsnfs1 and afsnfs2

One of the arguments to the kernel process is the location of the BOOTFILE that does the mounting.

The 'filename' argument (which can be over-ridden by the BOOTFILE argument for linuxRT) is as follows:

"/afs/slac/g/lcls/epics/iocCommon/ioc-b34-bd32/startup.cmd"

This script is similar to and modelled after RTEMS startup.cmd.

When linuxRT loads and start, the kernel process is run as "root" user.
Hence it has permissions to setup the nfs mounts which is done by the following line in startup.cmd:

/afs/slac/g/lcls/epics/iocCommon/All/Dev/linuxRT_nfs.cmd

Additional NFS Mount Points for linuxRT pertaining to the ioc data directory $IOC_DATA are mounted as well.

The next line in the startup.cmd file loads the linuxRT kernel modules.

More on kernel modules under question (10).

This can also be done only by the "root" user:

/afs/slac/g/lcls/epics/iocCommon/ioc-b34-bd32/kernel-modules.cmd

Next we must start the caRepeater process:

(http://www.aps.anl.gov/epics/base/R3-14/12-docs/CAref.html#Repeater)

"When several client processes (virtual iocs) run on the same host it is not possible for all of them to directly receive a copy of the server beacon messages when the beacon messages are sent to unicast addresses, or when legacy IP kernels are still in use. To avoid confusion over these restrictions a special UDP server, the CA Repeater, is automatically spawned by the CA client library when it is not found to be running. This program listens for server beacons sent to the UDP port specified in the EPICS_CA_REPEATER_PORT parameter and fans any beacons received out to any CA client program running on the same host that have registered themselves with the CA Repeater. If the CA Repeater is not already running on a workstation, then the "caRepeater" program must be in your path before using the CA client library for the first time."

So we add the following lines to startup.cmd to start a caRepeater for all EPICS VIOCs that may be hosted by this CPU:

export EPICS_CA_REPEATER_PORT=5067

su laci -c /afs/slac/g/lcls/epics/R3-14-12-3_1-0/base/base-R3-14-12-3_1-0/bin/linuxRT-x86/caRepeater

Finally, it is possible to automatically startup one or more EPICS IOCs right here and detach them using the linux screen program.

We can start another shell such that a user called "laci" can start the IOC process instead of the "root" user:

su laci -c /afs/slac/g/lcls/epics/iocCommon/ioc-b34-bd32/startup-laci-rt.cmd

More on startup-laci-rt.cmd under Question (13).

Under linuxRT,  a few real time processes that need real time scheduler and kernel memory locking features, can be specifically run as such.

The screen process does not need or have RT priority.

 The _MAIN_ thread in epics application process, which is started  doesn't have the RT priority either.

But, other threads which are created by the _MAIN_ thread may need RT priority.

Kukhee provides some information about this to find out which processes are running with real-time priorities:

Command to look up thread priorities