No systemd init script for orchestrator

[sjmudd]

Just a reminder. If I get time I´ll try and write one but I use systems which use systemd for starting processes. The BSD init scripts provided in the current code work but a systemd version would be better.

This issue is to just reflect that this is missing. Usage would depend on the OS you are using.

[igroene]

Here is a simple one I wrote:

[Unit]
Description="orchestrator: MySQL replication management and visualization"
After=syslog.target network.target

[Service]
Type=simple
ExecStart=/usr/local/orchestrator/orchestrator --verbose http
PIDFile=/var/run/orchestrator.pid
WorkingDirectory=/usr/local/orchestrator

[Install]
WantedBy=multi-user.target

Place in file /etc/systemd/system/orchestrator.service

[laurent-indermuehle]

Thanks @igroene.
I rely on a mysql backend so I modified the "After" parameter, to avoid Orchestrator starting befor MySQL is ready:

[Unit]
Description="orchestrator: MySQL replication management and visualization"
After=syslog.target network.target mysqld.service

[Service]
Type=simple
ExecStart=/usr/local/orchestrator/orchestrator --verbose http
PIDFile=/var/run/orchestrator.pid
WorkingDirectory=/usr/local/orchestrator

[Install]
WantedBy=multi-user.target

[mcrauwel]

This issue has bee mostly fixed by #915

However @Honiix suggestion is still valid, I ran into the same issue today.

[laurent-indermuehle]

@mcrauwel This has been addressed here: #1012 and release in 3.1.4.

Are you using an older version?

[mcrauwel]

@Honiix yeah that documentation piece describes how you can solve it, however it's safe to add the After= entry in the actual service-file. After does not force the relationship, it just kindly requests to systemd, if you start both services, please make sure MySQL starts first and only then attempt Orchestrator.

On the other hand I believe what the documentation currently suggests is to update the /etc/systemd/system/orchestrator.service file. This file is managed by the orchestrator package and if you alter this you have the risk that any (unattended/automated) package upgrade might fail or it might overwrite your change (depending on how you automated it). Systemd has support for override files so you don't have alter the the file managed by the package. I've drafted a blog post about this problem at https://blog.pythian.com/orchestrator-fails-to-start-after-reboot-using-systemd/. Check it out.

cc: @shlomi-noach

[laurent-indermuehle]

@mcrauwel My eyes always miss the github hint about PR in feeds, so my comment was misinformed. I warmly thank you for all your tests on #1112 . Having a service-file that always works and doesn't need manual configuration is far better than my solution.

[shlomi-noach]

systemd support was added a few months ago, and further improved by #1112