Made xxx.sh procServ-aware

[kmpeters]

xxx.sh can now be configured to run the IOC in procServ instead of screen.

This choice can be overridden on the command line with option arguments to the start subcommand:

$ ./softioc/xxx.sh 
Usage: xxx.sh {start|stop|restart|status|console|run|medm|caqtdm}

Additional options:
       xxx.sh start {screen|procServ|ps|shell}

[prjemian]

The command line arguments were initially modeled after starting as an /etc/init.d script, so the arguments fit that model. Will these changes be compatible with that model? Is that model still relevant?

[kmpeters]

The command line arguments were initially modeled after starting as an /etc/init.d script, so the arguments fit that model. Will these changes be compatible with that model? Is that model still relevant?

The addition of options for the 'start' subcommand doesn't appear to be compatible with that model. I don't think the model is still relevant, however. All the systems I have access to use systemd now.

If we wanted use systemd-like configurations for IOCs, there are helper utilities in procServ to do that, but that doesn't fit the access we have to machines at the APS.

[anjohnson]

Note that the version of systemd provided by RHEL-7 doesn't work properly for user-level application control, but the version in RHEL-8 does and at that point I will try to move our soft IOCs to start under systemd instead of the sysvinit scripts that we currently use. I haven't looked at the provServ helper scripts but I suspect they won't help us for the Accelerator IOCs.

[kmpeters]

@anjohnson what is the appeal of managing IOCs with systemd?

I use linux at home as my primary OS, so I'm somewhat familiar with systemd. I would expect most beamline scientists to have never heard of systemd. They have, however, been using versions of xxx.sh to manage soft IOCs for many years...

[anjohnson]

The Accelerator Controls group is responsible for many operational soft IOCs, and whenever their server gets rebooted they get started by a script that is run from an /etc/init.d entry, which IT has to install for us on every machine that is supposed to run soft IOCs. I would like more control over that process, and my understanding is that systemd can start services at boot time that are configured and run as regular unprivileged users. It can automatically restart services that die, it has logging capabilities, and you can easily query the status of one or more services. These are all things that we want for IOCs, so why not use the facilities provided by the OS if we can, instead of writing and maintaining our own code to implement them?

[kmpeters]

I am excited to see if systemd works well for accelerator IOCs.

[kmpeters]

Also, there is value in having a script like this in xxx, even if a systemd approach is preferred for the APS, to simplify the management of an IOC on non-systemd Linux distros and Windows.