Logstash: Provide systemd unit file

[dbrgn]

Would be nice if you could provide a systemd unit file in addition to the SysV and Upstart init scripts. Especially now that Debian 8 has moved to systemd by default.

[jordansissel]

In the meantime, you can use pleaserun to generate this:

# Run on your target server
% pleaserun -p systemd -v default --install /opt/logstash/bin/logstash agent -f /etc/logstash.conf
% systemctl enable logstash
% systemctl start logstash

[jordansissel]

Solving this I think will require packages that target specific OS distros and versions. We don't have this today, but will think about how to solve it.

[dbrgn]

In the meantime, you can use pleaserun to generate this

Thanks!

[putztzu]

So, this verifies why a logstash systemd Unit file doesn't exist.
Can someone explain then how my systemd commands (on an openSUSE 13.2) is hooked into supporting logstash installed from the official logstash repo? Should be the same as how LS would be installed on Fedora.

Someone must have done something very original to enable standard "systemctl enable/disable/start/restart/stop logstash.service" to perform without a Unit file. Unless the magic is somehow not in the logstash codebase and a new feature in systemd I'm not aware of (auto support of initV by scanning /etc/init.d/ and simulating Unit files?)

TIA.

[jordansissel]

Someone must have done something very original to enable standard "systemctl enable/disable/start/restart/stop logstash.service" to perform without a Unit file

Systemd has magic to have scripts in /etc/init.d/xxx appear implicitly as systemd services so they can be controlled from the normal systemctl start etc. This feature likely exists for backwards compatibility and easier transitioning to systemd, but that is just my guess.

Hope this helps explain.

[rgevaert]

@jordansissel systemd-sysv-generator generates on the fly unit files. However because of a design decision in systemd starting logstash doesn't work if logstash was not cleanly stopped (meaning through systemd stop).

Reproduce with (on a systemd enabled machine):
1) kill logstash process
2) systemctl start logstash
You will see that logstash isn't started.
3) systemctl stop logstash
4) systemctl start logstash
You will see logstash is started.

The reasons for this is that 'systemd-sysv-generator' by default puts "RemainAfterExit=yes". While it should be 'RemainAfterExit=no' for the [Service] block.

An override systemd section file can be found at https://gist.github.com/rgevaert/94094e94ffb420ab84a6

Here is a reference to a bugreport in discussing why systemd behaves this way. https://github.com/systemd/systemd/issues/1211

[m1keil]

@rgevaert Thank you for pointing in the right direction

[Xylakant]

Solving this I think will require packages that target specific OS distros and versions. We don't have this today, but will think about how to solve it.

Separate packages should not be required: common practice seems to be to just provide both an init script and a unit file. systemctl will ignore the init script if a unit file is present. Distributions that don't have systemd will ignore the unit file

[zabbal]

If you have trouble writing .service file you can take https://github.com/guardian/machine-images/blob/master/packer/resources/features/elk-stack/systemd-logstash.service as an example. But this really belongs to both upstream and packages.

[dhollinger]

@zabbal Nice job, though the .service file should not require elasticsearch.service since not all implementations of Logstash use the elasticsearch plugins for input or output.

I agree that this needs to be included in the DEB and RPM packages. Many, if not all, major distributions used in the Enterprise have switched over the SystemD for service management.

[Xylakant]

due to #4420 systemd might report a crashing logstash process as inactive (dead) instead of failed.

[strootman]

4420 has been closed.

[strootman]

It would be nice to have logstash install via systemd. At least for the sake of consistency with the other products (beats, elasticsearch, kibana).

[suyograo]

Fixed in #5341 available in 5.0.0-alpha3