MATTHEW Pondering more on weewx set up creating /etc/logrotate.d/weewx /etc/rsyslog.d/weewx.conf /var/log/weewx While these are all ineffectual as /var/log/weewx/weewx.log will never be created, there harmless and silently ignored. There may be a good reason to create them anyway. If a user decides to install the debian rsyslog package AFTER they have install WeeWx it will install logrotate as well as a dep. Then logging will start to be written to /var/log/weewx/weewx.log I have verified logging this on a test system. I assume that logrotate will honor the settings in /etc/rsyslog.d/weewx.conf and work as well, I did force a manual log rotate on weewx and it worked Paul
On Friday, December 15, 2023 at 10:31:39 AM UTC-5 matthew wall wrote: On Friday, December 15, 2023 at 10:05:13 AM UTC-5 Paul R Anderson wrote: I saw the conditional checks for /etc/logrotate.d /etc/rsyslog.d Yes those directories do in fact exist in a "pure systemd-journald" debian 12. Presumably they remain in place so older setup scripts don't fail. But their contents are silently ignored. Also noted you check later to see if /var/log/syslog exist. On Debian 12 "pure systemd-journald" /var/log/syslog Does Not EXIST If you checked that first , then nestled your /etc/logrotate.d and /etc/rsyslog.d under it would work in Debian 12, can't speak for any other OS the stat on /var/log/syslog is to ensure that we get the right permissions on the /var/log/weewx directory, since debian, ubuntu, and redhat each have different conventions for that. so far we have been able to have a single deb package work for a wide range of debian major releases. contrast this with the redhat world, where we *must* have a separate package for each major release. i think redhat is doing this syslog removal too, although they might have been less aggressive about eliminating syslog since so many enterprise installations have toolchains that depend heavily on syslog. journald is a poor (and less performant) substitute for syslog, ELK, or any infrastructure that uses syslog, not to mention the obfuscation and grief it causes when you try to diagnose systems that fail early in the boot process. yes, i have bias :) i'll revisit the conditionals. hopefully there is a path that serves both the windows-like, one-program-does-everything, reboot-if-it-fails, intended-for-a-laptop direction of systemd without sacrificing the needs of those who want a system to run reliably for a long time with minimal maintenance or update. m -- You received this message because you are subscribed to the Google Groups "weewx-development" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-development/09d8c852-b7d2-4bc8-b28d-7b7b4fea5b84n%40googlegroups.com.
