You can create systemd unit files from config. Some snippets are provided to help you easily define Linux servers. The resulting packages will automatically start the server on installation, restart it on boot, restart it if it terminates abnormally and stop/restart it across package upgrades. You can also lightly sandbox your server by running it as a non-root user.
To use this snippet
include "/stdlib/linux/service.conf", like this:
1 2 3 4 5 6 7 8
Assuming you've followed the standard conventions found elsewhere in this guide, this is enough to integrate your app with the service manager. The service will by default be named using the
Install the package and it should start the server. Try
systemctl status myvendor-awesomeapp to see if the server is running.
Adding additional command line arguments¶
SystemD uses the
ExecStart key to decide what to run. Therefore, you can add command line arguments that will only be passed when started from the service manager like this:
1 2 3 4 5 6
Note the escaping required to pass a command line argument that contains a space - just using quotes isn't sufficient because it won't be preserved through the config parsing process.
Setting default environment variables¶
Default environment variables are easy to add. Just remember to append to the list, not replace it:
1 2 3 4 5 6
More than one service¶
You can define as many systemd units as you like, but if you include the
service.conf snippet you'll have to pick your own file names for the others to avoid conflicts. Here's an example for a program that can be run in both "frontend" and "backend" mode where they should be started and controlled separately.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
Sandboxing the server¶
To make the server run as non-root, you can
include "/stdlib/linux/lightweight-service-sandbox.conf". This uses systemd's dynamic user feature to implement traditional UNIX unprivileged user sandboxing, but without the need to actually create users and groups in the install scripts.
Because the server won't run as root you won't be able to open ports lower than 1024. If your server is an HTTP server consider using a reverse proxy and Conveyor's built in ability to generate canned Apache/nginx reverse proxy configs (see the Linux section of the guidebook).
The server will be restricted to only writing to its private directories under
/var, which can be found in the
CACHE_DIRECTORY environment variables. Pay attention to them to make your software easier to run as a Linux server.
SystemD and the Linux kernel have many advanced sandboxing features which this simple standard library snippet doesn't use, but because you can control the unit files yourself you can define any policy you wish. Learn more about what keys are available.
Writable server files¶
Sometimes servers not written for UNIX or which were not designed to be packaged want to write to their own installation directory. It's not a good idea as it requires reducing the security of the server quite considerably (any compromise can be made permanent), but if you need this you can do it by using
The default service configuration looks like this:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40
1 2 3 4
1 2 3 4 5