Background
We can adapt our systemd implementation to be more in line with normal systemd services.
As a user/system admin, I prefer reading a simple script in /etc/init.d/kolibri to understand how to run and configure a system service.
As a developer/maintainer, I prefer systemd as it is easier to define services, and we can remove all of kolibri's daemon behavior.
But in light of issues ( #90 ) with the systemd daemon, we could want to maintain a pattern that separates the sysvinit script from systemd and lets systemd manage Kolibri as a New-style daemon.
Example
Here's how simple Kolibri's service file could be, given that we just let systemd manage everything:

What doesn't work in this example is that systemd will kill and respawn Kolibri too fast when it does reloads. Kolibri won't be able to re-bind to its TCP port that quickly.
A full implementation
Systemd is designed with patterns for users to override distributed files, e.g. sudo systemctl edit --full kolibri will create a local replacement, and sudo systemctl edit kolibri will amend to the distributed configuration. These are patterns that maybe people will get more used to in the future, as opposed to editing /etc/init.d/kolibri and such anti-patterns.
- We can keep the service's user configuration in
/etc/kolibri such that it's shared with.
/etc/default/kolibri stops being used.
/etc/kolibri/conf.d to ONLY support setting environment variables. Essentially nothing changes since we never documented anything else than setting the environment there.
- Ensure that
sudo service kolibri start also uses the systemd service. CLARIFY
- Kolibri could adapt to being supervised, like for instance
redis --supervised. Maybe we can just use --foreground or make an alias --supervised which we adapt in case behavior changes later.
Ingredients for writing a new systemd service:
- Load distributed daemon.conf:
EnvironmentFile=/etc/kolibri/daemon.conf UNCHANGED
- Load user added environment:
EnvironmentFile=/etc/kolibri/conf.d/*.conf UNCHANGED
- Set
User and Group in [Services]: /etc/systemd/system/kolibri.service.d/user.conf example. This would mean to either stop using /etc/kolibri/username and/or add a utility script that moves it CHANGED
Background
Background
We can adapt our systemd implementation to be more in line with normal systemd services.
As a user/system admin, I prefer reading a simple script in
/etc/init.d/kolibrito understand how to run and configure a system service.As a developer/maintainer, I prefer systemd as it is easier to define services, and we can remove all of kolibri's daemon behavior.
But in light of issues ( #90 ) with the systemd daemon, we could want to maintain a pattern that separates the sysvinit script from systemd and lets systemd manage Kolibri as a New-style daemon.
Example
Here's how simple Kolibri's service file could be, given that we just let systemd manage everything:
What doesn't work in this example is that systemd will kill and respawn Kolibri too fast when it does reloads. Kolibri won't be able to re-bind to its TCP port that quickly.
A full implementation
Systemd is designed with patterns for users to override distributed files, e.g.
sudo systemctl edit --full kolibriwill create a local replacement, andsudo systemctl edit kolibriwill amend to the distributed configuration. These are patterns that maybe people will get more used to in the future, as opposed to editing/etc/init.d/kolibriand such anti-patterns./etc/kolibrisuch that it's shared with./etc/default/kolibristops being used./etc/kolibri/conf.dto ONLY support setting environment variables. Essentially nothing changes since we never documented anything else than setting the environment there.sudo service kolibri startalso uses the systemd service. CLARIFYredis --supervised. Maybe we can just use--foregroundor make an alias--supervisedwhich we adapt in case behavior changes later.Ingredients for writing a new systemd service:
EnvironmentFile=/etc/kolibri/daemon.confUNCHANGEDEnvironmentFile=/etc/kolibri/conf.d/*.confUNCHANGEDUserandGroupin[Services]:/etc/systemd/system/kolibri.service.d/user.confexample. This would mean to either stop using/etc/kolibri/usernameand/or add a utility script that moves it CHANGEDBackground