mtail
mtail copied to clipboard
systemd .service startup file?
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 https://github.com/google/mtail/issues/262#issuecomment-526671101 @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
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"
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?
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.
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? :)
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.
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.
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.
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.
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.
I was indeed quite perplexed by that subshell-exec foo in the Debian file. :)