systemd .service startup file?

[anarcat]

Anyone has a working .service file for starting mtail in systemd? I'd like to improve on systemd integration in Debian to replace the old sysvinit-based startup we currently use...

In #262 (comment) @antobaldu mentions using systemd to run mtail, but I haven't found a good sample one...

I might write one myself but I figured I would ask before duplicating work. Thanks!

This was also reported in the Debian bugtracker: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=886894

[ionutvilie]

Hi, maybe this helps. it's from a Ubuntu VM.

(I am not the author, I have no idea of its source, but it works)

• /etc/systemd/system/mtail.service

[Unit]
Description=mtail

[Service]
EnvironmentFile=/etc/default/mtail
ExecStart=/usr/local/bin/mtail $ARGS

Restart=always
OOMScoreAdjust=1000
Nice=19

[Install]
WantedBy=multi-user.target

• environment file: /etc/default/mtail

ARGS="-progs /usr/local/etc/mtail"

[anarcat]

i ended up writing my own as well based on a friend's incantation, here's what i came up with:

[Unit]
Description=MTail

[Service]
Type=simple
EnvironmentFile=/etc/default/mtail
ExecStart=/usr/bin/mtail --progs /etc/mtail --logtostderr --port 3903 --logs $LOGS
Restart=on-failure
User=mtail

# Limit memory leaks
MemoryMax=1G
ExecStartPost=+/bin/sh -c "echo 0 > /sys/fs/cgroup/memory/system.slice/%n/memory.swappiness"

[Install]
WantedBy=multi-user.target

what is OOMScoreAdjust=1000 and Nice=19 for?

[slvr32]

I have the following in a puppet template/erb, to support at least some of the mtail options

[Unit]
Description=Mtail
After=network.target

[Service]
ExecStart=<%= @mtail_binary %>
-progs <%= @mtail_progs_dir -%>
<% @mtail_logs.each do |log| -%>
-logs <%= log -%>
<% end -%>
-emit_prog_label=false
-logtostderr
ExecReload=/bin/kill -HUP $MAINPID
Restart=always

[Install]
WantedBy=multi-user.target

I know puppet code is beyond the scope of mtail source/packaging, but I also wrote an mtail profile to manage mtail installation, service management, programs, etc... since there doesn't happen to be anything on puppet forge to do the same.

[anarcat]

i ended up writing my own as well based on a friend's incantation, here's what i came up with:

and... fwiw that is somewhat what shipped in debian recently:

https://sources.debian.org/src/mtail/3.0.0~rc48-3/debian/service/

logs come from the EnvironmentFile=/etc/default/mtail

I know puppet code is beyond the scope of mtail source/packaging, but I also wrote an mtail profile to manage mtail installation, service management, programs, etc... since there doesn't happen to be anything on puppet forge to do the same.

i really need to publish to the forge, but i use this in puppet: https://github.com/anarcat/puppet-mtail

maybe we should collaborate? :)

[jaqx0r]

Collab on anarcat/puppet-mtail sounds like a great idea.

FWIW if you want to send a PR with a systemd init file in the top level directory I'll take it.

[tacerus]

In case this is still relevant, here is the service unit file we ship with the openSUSE package:

https://build.opensuse.org/package/view_file/server:monitoring/mtail/mtail.service

It contains various hardening options which might be good practice.

[anarcat]

oh wow, yeah, that's a great unit file!

@tacerus could you submit that as a PR? @jaqx0r explicitly said they would look at one, if we provide it. happy to provide a review as well.

[tacerus]

Sure! I think the only part which is somewhat SUSE specific convention is sourcing $ARGS from /etc/sysconfig/, I think some other distributions use /etc/default and varying variable names.

But those are probably reasonable to patch downstream as needed.

[anarcat]

On 2024-03-07 09:35:45, Georg wrote: Sure! I think the only part which is somewhat SUSE specific convention is sourcing `$ARGS` from `/etc/sysconfig/`, I think some other distributions use `/etc/default` and varying variable names. But those are probably reasonable to patch downstream as needed.

Yeah, that seems reasonable. A drop-in file can fix that parameter as well. (FWIW, I believe RHEL also uses sysconfig...) The Debian unit file actually explodes the various arguments (instead of delegating to a plain ARGS) which makes it overly complicated (e.g. it shells out to `sh -c`), so I wouldn't recommend following *that*.

[tacerus]

I was indeed quite perplexed by that subshell-exec foo in the Debian file. :)