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.

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.

You're totally right. Systemd did accept it but according to the documentation it should be "forking".

I will correct the post