Re: [Sks-devel] SKS logging to syslog using 1.1.6-2~bpo8+1 from debian-packports

[Daniel Kahn Gillmor]

Hi John and Pete--

On Sat 2016-12-03 21:27:52 -0500, John Zaitseff wrote:
> ====
> # /etc/systemd/system/sks-recon.service.d/override.conf
> # [JNZ] Modified 19-Nov-2016 for keyserver.zap.org.au
>
> [Service]
> ExecStart=
> ExecStart=/usr/sbin/sks recon
> ====
>
> ====
> # /etc/systemd/system/sks.service.d/override.conf
> # [JNZ] Modified 19-Nov-2016 for keyserver.zap.org.au
>
> [Service]
> ExecStart=
> ExecStart=/usr/sbin/sks db
> ====

this does indeed remove the logging of sks to stdout (it drops the
-stdoutlog argument), and causes sks to manually manage its logs, so it
is one way to meets Pete's goals.

But let me explain why i think leaving the logs going to stdout is a
better long-term solution (and indeed, why that will continue to be the
default in debian).

sks has enough to do with managing its network requests (it doesn't even
really do that very well, considering that it needs to be behind an HTTP
reverse proxy to operate safely on the internet).  Managing a logfile,
and having to close and re-open the logfile during logfile rotation is
yet another complication that sks really shouldn't need to deal with.

If sks logs to stdout, it just writes to a file descriptor and then
never thinks about it again.  This is better for sks, because it gives
it less to "think" about.

so the question is: who handles that file descriptor?  under systemd,
that output fd is input to journald, which writes its data to
/var/log/journal, and to any other authorized consumers.  the journal
can be queried with, e.g. "journalctl --since yesterday --unit sks", and
the last few entries can be seen with "systemctl status sks" or
"systemctl status sks-recon" as part of an easy service state overview.

if you've got syslog or syslog-ng or rsyslog hooked up into journald,
then they accept new log entries and write them to disk in /var/log.

So the question is: why do you care that the logs are written to
/var/log/sks?  if what you want is logs that can be found consistently,
i encourage you to review the output of journalctl.  Alternately, if you
really need /var/log/sks/ for whatever reason, and you're running one of
the variants of syslog, i believe you can configure the way that
journald is connected to the syslog daemons so that logs from a given
service get written to a specific logfile.  I don't know which syslog
you're using, so i can't provide more details than that, though.

If you take that approach, then "systemctl status sks" will still work
for you, *and* you'll get files in the expected place, *and* you'll get
any future upgrades to the sks{,-recon}.service files provided by the
package manager.

Hope this helps,

     --dkg

signature.asc
Description: PGP signature