Hello
I have noticed that Cache (2016.1 at the time of writing) doesn't come with a systemd startup script for RHEL7.
Here is a small example script I have built.
[Unit] Description=Intersystems Cache [Service] Type=forking ExecStart=/bin/bash -c '/usr/cachesys/cstart 2>&1 | logger -t cache_start' ExecStop=/bin/bash -c '/usr/cachesys/cstop quietly 2>&1 | logger -t cache_stop' RemainAfterExit=yes [Install] WantedBy=multi-user.target
The file should be placed as /usr/lib/systemd/system/cache.service
After saving the file, use these commands to install and run the Cache service
systemctl enable cache systemctl start cache
Hope you find it useful!
Isaac
You have a typo. The service type should be forking not fork.
George
You're totally right. Systemd did accept it but according to the documentation it should be "forking".
I will correct the post
I'd like to add a couple of comments about using systemd/systemctl with Caché.
First, if you have more than one instance on your machine, you might want to use ccontrol in the Caché systemd Unit to start/stop a particular instance. In that case you could name the file as cache-<instance name>.service.
The second point is that if you want to use systemctl to start/stop Caché, then you should always use it. Mixing systemctl with manual use of ccontrol is fine most of the time, but could cause unexpected results in some situations.
Consider the following sequence of events.
1) Caché is started by systemctl. If you ask for the instance status, systemctl will display a full process tree.
2) ccontrol stop <instance>
3) If you ask for systemctl status now, it will notice that the instance is inactive but will think it is dead.
4) ccontrol start <instance>
5) systemctl status cache-<instance> still reports that the service is inactive (dead) when in reality it is up and running.
So the takeaway point is that systemd can lose its status about Caché if you stop/start it manually with ccontrol or cstart/cstop.
In the above situation, if you inadvertently proceeded to shut down the OS without shutting down the Caché instance first, systemd would not invoke its ExecStop command because it would think the instance was already down.
My example is indeed intended for the classical use of one instance.
I think the simplest way to solve the reporting issue is to provide a PID file. If Cache provides one the systemd can check for a running process under that PID.
PIDFile=Takes an absolute file name pointing to the PID file of this daemon. Use of this option is recommended for services whereType=is set toforking. systemd will read the PID of the main process of the daemon after start-up of the service. systemd will not write to the file configured here, although it will remove the file after the service has shut down if it still exists.Another possible solution is to have a switch telling Cache not to fork and then run the service using Type=simple.
I think the average system administrator is aware of fact that changes to the service's state not made by systemd might not reflect well on systemd. The same behavior occurs when you use Apache's or Postfix's service initializations commands directly.
I forgot to mention that we are investigating ways to improve the coexistence of Caché with systemd, but we haven't reached a final design yet.
Jose,
"RemainAfterExit=yes" setting seems to address the loosing service status issue you mentioned. (Have no RHEL/CentOS 7 at hand to check it).
Well, if you don't use "RemainAfterExit=yes", what happens is that systemd sends a signal to the cache main process and Cache shuts down right after it started.
Systemd's approach to "forking" expects the command to exit after having the main process forked and detached. There is probably something that doesn't fulfill systemd's expectations which makes it believe the process has not forked or there may be something remaining.
RemainAfterExit simply tells systemd that it's OK for the started process to remain running.
Here is a script I've been using recently.
It can easily be adapted to different instances on one machine. As Jose already pointed out, one should stick to one method of managing the instance state and not mix them.
[Unit] Description=Intersystems Cache [Service] Type=forking ExecStart=/usr/local/etc/cachesys/ccontrol start cache ExecStop=/usr/local/etc/cachesys/ccontrol stop cache quietly RemainAfterExit=yes [Install] WantedBy=multi-user.target