Following up on #295 and #297 (Thanks for implement this!)
I'd like to ask if an enhancement like --wait-for-lock would make sense.

Scenario:

1. We'd like to tap into the global statefile i.e. /var/lib/logrotate/status i.e. to avoid confusion and error when having separate status file
2. There might be several cronjobs set up to run every full hour, but managed via separate cronjobs (or systemd timers)
3. It would be OK that they run in sequence, i.e. "as close as possible to the original timestamp".

Think about deploying your config into /etc/logrotate.d/ so that admins find the configuration easily;
but preventing logrotate erroring out due to "lock file exists"; or preventing multiple state files where you can get unexpected results when using
(a) a custom logrotate -s ... call vs.
(b) daily logrotate call from the distribution vs.
(c) accidential calls via logrotate /etc/logrotate.d/someconfig

Note: I did consider to implement while locked; do sleep $RANDOM; done && logrotate /etc/logrotate.d/someconfig i.e. by using "fuser" or "lslocks", but I can still imagine race conditions and/or hard to foresee corner cases.

Thanks,
Raoul