Comment # 1 on bug 1112500 from Andrew Daugherity

I have successfully implemented the systemd timer solution, based on the
upstream definitions from logwatch git:
====
adaugherity@wp:~> systemctl list-timers
NEXT                         LEFT        LAST                         PASSED   
    UNIT                         ACTIVATES
Wed 2018-10-24 00:00:00 CDT  10h left    Tue 2018-10-23 00:00:01 CDT  13h ago  
    logrotate.timer              logrotate.service
Wed 2018-10-24 00:00:00 CDT  10h left    Tue 2018-10-23 00:00:01 CDT  13h ago  
    logwatch.timer               logwatch.service
Wed 2018-10-24 02:30:01 CDT  12h left    Tue 2018-10-23 02:30:01 CDT  11h ago  
    systemd-tmpfiles-clean.timer systemd-tmpfiles-clean.service
Mon 2018-10-29 00:00:00 CDT  5 days left Mon 2018-10-22 00:00:01 CDT  1 day 13h
ago fstrim.timer                 fstrim.service

4 timers listed.
Pass --all to see loaded but inactive timers, too.
adaugherity@wp:~> systemctl status logwatch.service logrotate.service
��� logwatch.service - Log Analyzer and Reporter
   Loaded: loaded (/etc/systemd/system/logwatch.service; static; vendor preset:
disabled)
   Active: inactive (dead) since Tue 2018-10-23 00:00:22 CDT; 13h ago
     Docs: man:logwatch(8)
           man:logwatch.conf(5)
 Main PID: 32704 (code=exited, status=0/SUCCESS)

��� logrotate.service - Rotate log files
   Loaded: loaded (/usr/lib/systemd/system/logrotate.service; static; vendor
preset: disabled)
   Active: inactive (dead) since Tue 2018-10-23 00:01:30 CDT; 13h ago
     Docs: man:logrotate(8)
           man:logrotate.conf(5)
 Main PID: 677 (code=exited, status=0/SUCCESS)
====

Both logwatch.timer and logrotate.timer use OnCalendar=daily, but by adding
Before=logrotate.service to logwatch.service, logwatch always runs first. 
(Note: this is in the *service* file, not the timer file.  systemd doesn't
complain about Before= or After= settings in timer files, but they don't do
anything!)

With this timer solution, the /etc/cron.daily/0logwatch symlink must be
removed.  I will attach the logwatch.{service,timer} files to this bug; I could
also submit them to the OBS package in server:monitoring if desired.