Experimental Physics and
Industrial Control System

Ralph Lange <[email protected]> · Thu, 20 Mar 2014 12:43:25 +0100

On 20.03.2014 11:59, Jeong Han Lee wrote:

Hi,

 We have one network file server (A), where I installed EPICS and

its extensions in /data/programs/epics/{base,extensions}. In A,

EPICS_BASE is /data/programs/epics/base.

 We mount the directory as /mnt/glusterfs on a local Linux PC (B),

all uid and gid is the same. In B, EPICS_BASE is

/mnt/glusterfs/programs/epics/base.

 The main issue which I've found until now (maybe something more

hidden issues, because I didn't test it fully) on softIOC, which has

the Compiled-in path inside the binaray files. Just shortly look at

Makefile and softMain.cpp, and makeInstallDir.pl, the EPICS path is

saved into the binary file when it compiles.

 I know how to work around this issue by using softIOC -D option.

However, I know EPICS community has the better solution, any

suggestions, or potential issues which I don't know right now.

Hello Han,

I would not recommend this setup.

While putting executables and libraries on an NFS share is easy and Just

Works [tm] when you set it up, it will create painful difficulties later on.

To work reliably, *all* client machines need to be on (more or less) the

same version of the same Linux distribution. Any crucial change in the

system libraries of a client, and everything on that client might stop

working immediately (the easy case) or just become instable and

sometimes crash for no obvious reasons (the painful case).

In such a setup, updating your machines to a new Linux version becomes

basically an all-or-nothing operation, requiring a huge time slot for

testing and verification. Also, your development machine will always

have to be on the oldest version around, to generate code that is

compatible with all your client machines.

Using an NFS share is fine for all non-binary data (EPICS IOC databases,

startup scripts, autoSaveRestore data, logs, ...), but I would always

recommend keeping binaries and libraries locally on your production

machines. The easiest and safest way is to use your system's style of

binary packages, but rsync'ing from your development machine is

basically fine, too - in that case you are responsible for tracking the

dependencies.

If you put the installation in the same place on all machines, that

could be the path that you compile into the softIOC.

Note, though, that this softIOC binary in base is intended for

development use. Most of your real-life soft IOCs will need driver code

(asyn, stream, ...) and come as binaries that are created in an IOC

application, and then deployed on your production systems.

Cheers,
~Ralph