You have a bunch of SDL Tridion Content Delivery microservices set up in various locations. In Windows, these can be installed as Windows Services, which allow you to configure automatic start rather easily, via the Services interface. But how can you do the equivalent in Linux?
/<path>/services/staging/discovery/<path>/services/staging/session/<path>/services/staging/preview/<path>/services/live/discovery/<path>/services/live/deployeretc.
You may have seen posts that recommend using an init.d script (i.e. you write a .sh file with a specific format defining start() and stop() operations, place it in the /etc/rc.d/init.d directory, etc.). However, newer Linux distributions, such as Red Hat Enterprise Linux 7.4, have been adopting the systemd init system, which works a little differently. When you look at the /etc/init.d/README, it clearly states that the OS is systemd-based and that traditional init scripts have been replaced by native systemd service files.
So how does it work?
First, you create a file with a .service extension and place it in the /etc/systemd/system directory. For example, staging-discovery.service:
 [Unit]
 Description=SDL Content Delivery Staging Discovery Microservice
 After=syslog.target network.target remote-fs.target nss-lookup.target
 [Service]
 Type=forking
 ExecStart=/<path>/services/staging/discovery/bin/start.sh
 ExecStop=/<path>/services/staging/discovery/bin/stop.sh
 User=<user>
 PIDFile=/<path>/services/staging/discovery/sdl-service-container.pid
 [Install]
 WantedBy=multi-user.target
Then you run a command to tell systemd to start this service at boot. This creates a symlink in the specified target folder:
 sudo systemctl enable staging-discovery.service
That should be it! Now when you reboot your server, you should see your microservice running on the port you assigned it to. You could run something like this to check:
 ps -ef | grep <user>
 netstat -tulpn
Notice the Type is set to forking. You may be able to get it sort of working with Type=simple or Type=oneshot. However, if you try that, you will likely notice that you are no longer able to shut down your microservice manually by running ./stop.sh directly. This is because the start.sh script forks the process into a new PID (using the ‘&’ operator). So Type=forking and PIDFile tell systemd which new process your microservice is running under, so that it runs independently of the start.sh process and systemd knows how to stop the microservice, when required.
Notes:
- The .pid file is created and deleted by your microservice, as needed
- The Cache Channel Service uses a different filename for its .pid file
- If you are testing by running systemctl start, you may have to run it a second time if it fails on the first attempt
- If you start a service manually, by running the start.sh file directly, that should be fine. Note, however, that you will not be able to stop it by running systemctl stop, since systemd will not be aware of which PID is being used to run the service
- The steps in this post are not specific to SDL Tridion. The same approach could be used for any startup automation that uses shell scripts.