On Mon 2016-12-05 09:37:13 -0500, Pete Stephenson wrote: > 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.
hm, i think i agree with you there, but the default should *actually* be to log to stdout or stderr. there are a lot more subtleties, corner cases which can break, and potential permissions problems if the daemon has to open and write to and close the file, and respond to logrotation events, even if it doesn't manage the rotation itself (e.g. what happens to a file if it's copy+truncated while i'm holding it open to write to it?) writing to a known file descriptor and then forgetting about it is the simplest possible thing :) > 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. the idea is that it's a system service manager -- it knows how to start and stop services, what to do with their output, how to keep track of any children they might spawn, how to clean them up, what resources to give them, etc. This is what an init system *should* do, since it's well-placed to see all the pieces of the puzzle and to help keep them isolated where possible and connected where necessary. > 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. rsyslog receives its input from journald at /run/systemd/journal/syslog, as standard syslog messages, annotated with identity, facility, and priority (see syslog(3) for a common library interface used by clients to write this information) It then writes them to various files, as determined by the properties mentioned above, matched as described in rsyslog.conf(5). On debian jessie, you should be able to drop a file in /etc/rsyslog.d/sks.conf that contains directives to produce the old /var/log/sks/*.log files, using the expected permissions, etc. Only now, you don't actually need to have those files writable (or readable) by the sks-debian user account at all; the logging is independent of the daemon, and if the daemon is ever compromised, it can't overwrite its logs. if you come up with a reasonable /etc/rsyslog.d/sks.conf that you think would work for other people who happen to run rsyslog in addition to systemd, i'd be happy to ship it in the debian package to support that use case. If you decide to do that, you can mail it to the list here, or you can report it via the debian BTS using "reportbug sks". Happy hacking, --dkg
signature.asc
Description: PGP signature
_______________________________________________ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel