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

[Pete Stephenson]

On Mon, Dec 5, 2016 at 3:01 PM, Daniel Kahn Gillmor
<address@hidden> wrote:
> Hi John and Pete--

Hi Daniel,

> 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.

While I agree that a program should focus on the one thing it does
well, writing a logfile seems to be a pretty basic thing.

I recall that other tools like logrotate can deal with various
oddities of certain logfiles even if the program writing the logs
doesn't play nice. For example, NTPd can be really chatty with the
Motorola Oncore driver (writing a bunch of data to syslog every
second), so I recompiled it so it can write that to a separate log
defined in the config file. It never closes that file for rotation,
but logrotate can "copytruncate" the file and that has the same
result.

Either way, it seems strange that SKS is ignoring the "logfile: log"
line I explicitly put in the sksconf file in favor of the -stdoutlog
arguement in the .service file.

I don't mind having certain behavior be the default -- and, as you
say, there are good reasons for having that be the default -- but
user-added entries in the config file should take precedence.

> 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.

You're right, if one uses systemd then keeping everything in the
systemd ecosystem makes sense.

Without wanting to reignite the systemd holy war, my use of systemd to
this point has been as an init system, and I have no problem with
that. It does what I need it to reasonably well and I have no
particular complaints.

However, using it as a logging system is strange to me. Years of
habitually using tools like tail to follow log files and having
logrotate rotate them day-by-day and gzip old logs is a bit of an
obstacle to overcome for something that, IMHO, doesn't seem to do
anything particularly better...but I'm willing to learn.

I'm using a bog-standard Debian Jessie installation and it appears to
be using rsyslog. I'm not familiar with how rsyslog and systemd
interact in regards to logging, but if you have any advice to point me
in the right direction I'd be very much obliged.

> Hope this helps,

It does, indeed. Thank you for the response.

Cheers!
-Pete

-- 
Pete Stephenson