New post
Article
· Nov 22, 2019 1m read

Starting IRIS as a service on CentOS7 startup ( autostart )

#InterSystems IRIS

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
[Unit]
Description=Intersystem IRIS Service
After=network.target
[Service]
Type=forking
WorkingDirectory=<iris-install-dir>
User=root
ExecStart=<iris-inst-dir>/bin/iris start "<instance>"
ExecStop=<iris-inst-dir>/bin/iris stop "<instance>" quietly
Restart=on-abort
[Install]
WantedBy=default.target

<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

  or

# systemctl stop iris.service

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

# systemctl enable iris.service

Hope this helps.

Discussion (10)3
Log in or sign up to continue
Pete Greskoff · May 8, 2020

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.

3 0
Anzelem Sanyatwe · May 9, 2020

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.

0 0
Nick Zhokhov · Mar 2, 2021

If ce/iris is started by ccontrol /iris start 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 /etc/systemd/logind.conf  KillUserProcesses=yes then after user logout and  user session destruction
sibling processes might get signal (default SIGTERM) and handler might do process exits.
Some ce/iris system daemons are terminated (mainly started by startup STU), some are not terminated (mainly control and those are forked from it).
Another thing is /etc/systemd/logind.conf  RemoveIPC=yes.
systemd might just remove ipc resources owned by cache instance resulting cache kernel is not working
correctly in very base stuff.
Shortly it is worth to reread man systemd-logind, man logind.conf, man loginctl.
Though systemd service wrapper for control/iris start is not quite consistent with direct use of ccontrol/iris start and systemd might lose correct service state but it never loses control on processes as being unix init process.
Direct usage of ccontrol/iris start|stop requires attention to logind.conf KillUserProcesses=no, RemoveIPC=no.
systemd service wrapper is worth to use as ccontrol/iris start|stop wrapper if system is managed by systemd.

I would use template variant.

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

[Unit]
Description='isc cache'
After=network.target
#After=network-online.target

[Service]

# 1st way oneshot
Type=oneshot
RemainAfterExit=yes
# end of 1st way

# 2nd way forking
#PIDFile recommended but might be absent
# Type=forking
# end 2nd way 

ExecStart=ccontrol start %i
ExecStop=ccontrol stop %i quietly

[Install]
WantedBy=multi-user.target

<end>

examples
systemctl start isccache@201772B865
systemctl status isccache@201772B865

systemctl stop isccache@201772B865

systemctl enable isccache@201772B865
systemctl disable isccache@201772B865

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

ce=cache or ensemble
1 0
Nick Zhokhov · Oct 2, 2020

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.
https://github.com/systemd/systemd/issues/17224

0 0