Don't use any shebang, as this is a simple service to start, not requiring complex pre-configuration or whatever.
Piping that way might break the supervision... you need to exec into the daemon in order to supervise it, and it isn't possible when you pipe it.
Kindly inspect the --logflags= or similar options if you can ask the daemon itself to not log that...
Yes, you can, of course, use s6-fghack and pipeline { syncthing } grep in execline itself.
Here's a frontend, which does everything except the "hardening" and the wierd keys...
[Main]
Type = classic
User = ( root ) # Not the daemon's user, the user who can start/stop/reload the daemon; multiple can be specified;
Version = 0.8.0
Description = "Syncthing - Open source continuous file synchronization"
MaxDeath = 3
#TimeoutStart = 60s # Is it StartLimitIntervalSec= of systemd? IDK, sorry
[Start]
RunAs = syncthing
Execute = (
/usr/bin/syncthing serve ${Args}
)
[Environment]
# The syncthing --home=
Syncthing_Home=!/opt/Data/Servers/configs/syncthing
# The HOME
HOME=/root
# Arguments to the service
Args=!--no-browser --no-restart --logflags=0 --home="${Syncthing_Home}"
# I will add more variables here for find-grained CLI arguments, once I myself see what syncthing is...
As for grep -ving, you can prepend this to Execute=(): (The ^ is needed to not grep-v lines like LOG: this INFO: where INFO: isn't at the beginning...)
(s6-fghack tracks forking or multiple processes, as a babysitter process via many FDs passed to the daemon)
s6-fghack
pipeline {
/usr/bin/syncthing serve ${Args}
} grep -v "^INFO: "
You can use setpriv in order to set up the "hardening", but that shouldn't be needed... If needed kindly reply, I'll write the script for using it...
As for filtering the log output, why do you need that? You can always grep -v "INFO: " /var/log/66/syncthing/whatever-log-file, and the logfile will contain all the logs.
If you really want to filter, you can configure the 66 frontend [Logger] section (but either the feature itself or it's documentation for that is unfortunately incomplete)...
Doubt @eric can we create our own ${service}-log frontends to override the default? Pulling the correct log pipes from 66's instance s6-fdholder and filteing via s6-log's regex-matching? @eric can we atleast specify the regex (and statusfile) via [Logger] or whatever?
