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.
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:
After changing the iris.service file one should perform:
2c more.
.service suffix is redundant in systemctl command, so one can just enter:
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 /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.
Nick,
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.
https://github.com/systemd/systemd/issues/17224
Great write up! Thanks, saved me lots of googling and trying methods that don't really work :)