Udo Leimberger · Nov 22, 2019 1m read

Starting IRIS as a service on CentOS7 startup ( autostart )

If you want to start IRIS as a service on CentOS7 you can use systemd.

Login as root and create a new file iris.service in /etc/systemd/system.

# vi /etc/systemd/system/iris.service
Description=Intersystem IRIS Service
ExecStart=<iris-inst-dir>/bin/iris start "<instance>"
ExecStop=<iris-inst-dir>/bin/iris stop "<instance>" quietly

<iris-install-dir> = Directory where you installed IRIS on Centos7 i.e. /iris

<instance> = The IRIS instance you want to manage.

After creating the file set the correct permission

# chmod 664 /etc/systemd/system/iris.service

Reload all Unit files of the service

# systemctl daemon-reload

  Finally start the service ( if IRIS was already started then stop it )

# systemctl start iris.service


# systemctl stop iris.service

If everything works fine you can enable the service at startup:

# systemctl enable iris.service

Hope this helps.

3 10 390 5


Thank you, Udo!

Just 2c to add.

Quotes are not needed in the following lines, due to the syntax of iris start/stop commands. They should look like:

ExecStart=<iris-inst-dir>/bin/iris start <instance>
ExecStop=<iris-inst-dir>/bin/iris stop <instance> quietly

After changing the iris.service file one should perform:

# systemctl daemon-reload

2c more. 

.service suffix is redundant in systemctl command, so one can just enter:

# systemctl start iris
# systemctl stop iris
# systemctl status iris

The published script pattern is applicable to Caché after evident correction (iris -> ccontrol).

Thanks for your comments

I just want to note that, although this script works at the basic level, using systemd with Caché/IRIS is not going to be a perfect experience. systemd relies on the fact that it's the only method being used for stopping and starting the service. If the instance is stopped or started via another method, such as a direct 'iris start/stop/force' by a user, or an 'iris force' invoked by the ISCAgent during a mirror failover, systemd will lose track of the actual status of the instance. Certainly, if you want to use this on a test system for basic functionality, you can, but I would definitely not recommend this on a live system.

to some extent i concur with the above sentiments. i actually use the old service method, i don't use systemd. e.g perfect use case in cloud environment where you need the instance to automatically start everything if you have an instance stop/start schedule to contain costs. As for Production, i have never implemented a script and prefer a controlled operation. This is mostly because Cache is too finicky when it comes to start-ups, and preferably you need to be present.

If ce/iris is started by ccontrol /iriss tart in systemd service context then it must to be stopped also in systemd context.
If one is used ccontrol/iris start directly there are consequences for system where init is systemd.
1 ce/iris processes are in cgroupv2 in user.slice hierarchy (more logical to have it in system.slice)
2 ce/iris processes are under systemd session and for example if KillUserProcesses=yes then after user logout from session
these processes get signals (default SIGTERM) and handler might do process exits.
Some ce/iris systemd daemons are terminated some is not terminated (mainly control and those are forked from it).
Though systemd service wrapper for control/iris start is not quite consistent with direct use of ccontrol/iris start
systemd service wrapper  is worth to use as ccontrol/iris start|stop wrapper.
I would use templated variant.

cat /etc/systemd/system/isccache@.service

Description='isc cache'

# way oneshot
# way forking
#PIDFile recommened but might be absent
ExecStart=ccontrol start %i
ExecStop=ccontrol stop %i quietly



systemctl start iscache@201772B865
systemctl status iscache@201772B865

systemctl stop iscache@201772B865

systemctl enable iscache@201772B865
systemctl disable iscache@201772B865

if systemd state is wrong or ce/iris shutdown fails.
ccontrol force 201772B865
systemctl stop iscache@201772B865
now it is ok for 
systemctl start isccache@201772B865

ce=cache or ensemble

May I ask you: where did this magic number (201772B865) come from?

Obviosly it is instance name
ccontrol qlist
ccontrol list

Also I reported systemd bug
purpose 1 run cache/iris as systemd service by not root user using polkit jscript , user must be in cache/iris management group. It is ok.
purpose 2 use systemd-run to start|stop cache/iris by ccontrol/iris  consistent way with systemd where user in cache/iris
management group. It is not ok and subject of systemd bug. root works ok.

Great write up!  Thanks, saved me lots of googling and trying methods that don't really work :)