Comment 2 for bug 2015896

I was able to catch this in a live environment and did some additional debugging.

The first note is that we only hit this bug running latest/edge, revision 12. The only configuration we set is `logrotate-retention: 60` and use defaults for everything else.

I dont have the live environment up any longer to get the _exact_ logs, but when i called the cronjob directly installed in /etc/logrotate_cronjob_config, and built on line 66 of lib_cron [1] the cronjob failed because it was trying to find a method in lib_cron called "None" [2]. When i looked at the cron_daily_schedule the values were to:
True
hourly
60
unset

This last value "unset" is the offending parameter, which is a new param for the edge/candidate version of the charm. This behavior may be expected overall, but could return a better message about being unset, instead of stuck "Executing cron job." when the hook is expected to fail. maybe return the message "cron schedule unset, please set to unblock charm."

1) https://git.launchpad.net/charm-logrotated/tree/src/lib/lib_cron.py#n66
2) https://git.launchpad.net/charm-logrotated/tree/src/lib/lib_cron.py#n157