© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
513534c
demo site
(Get the code!)
I wonder if it is pure rsyslog failure. At this stage, I am not convinced that we can do much on Juju side either way...
According to a search on similar failures in the wild, the actual cause could be a corrupt .qi file, see for example https:/
Corruption may happen when, for example, the recorded queue size is larger than the actual number of messages inside the disk queue. Juju does not explicitly control that, although there may be some configuration that you could to set for rsyslog. I suspect the rsyslog itself may need to be upgraded... Is that a possibility?
From what you describe above, it looks like that ever after removing the corrupt queue files and even on rsyslog restart, the disk queue cannot be properly initialised. I am not too sure if there is a way to process the corrupted queue files. I do wish we had a test environment where this failure could be easily re-produced to confirm the fix but I cannot see what Juju can do here.