Article
· Jun 21, 2016 1m read

Simple Cache systemd Unit

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!

Discussion (8)1
Log in or sign up to continue

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 where Type= is set to forking. 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.

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