NRPE checks fail due to malformed crontab entry
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OpenStack RabbitMQ Server Charm |
Fix Released
|
Undecided
|
Aurelien Lourot |
Bug Description
In a deployment rabbitmq-server charm was upgraded to revision 110 (on bionic, queens).
After the upgrade went successfully, nagios nrpe check starts to fail.
Checking the root cause shows that the new charm calls python3-croniter, which expects 5 or 6 columns in the crontab entries.
This is the output of the check rabbitmq queues, with added prints for which line fails (the collect_
root@juju-
['*/5', '*', '*', '*', '*', 'rabbitmq', 'timeout', '-k', '10s', '-s', 'SIGINT', '300', '/usr/local/
18
Traceback (most recent call last):
File "/usr/local/
for f in args.stats_file]
File "/usr/local/
for f in args.stats_file]
File "/usr/local/
interval = get_cron_
File "/usr/local/
it = croniter(cronspec, base)
File "/usr/lib/
raise ValueError(
ValueError: Exactly 5 or 6 columns has to be specified for iteratorexpression.
tags: | added: upgrade-charm |
Changed in charm-rabbitmq-server: | |
assignee: | nobody → Aurelien Lourot (aurelien-lourot) |
Changed in charm-rabbitmq-server: | |
milestone: | none → 21.10 |
Changed in charm-rabbitmq-server: | |
status: | Fix Committed → Fix Released |
The problem here is that the get_stats_ cron_schedule( ) function in check_rabbitmq_ queues splits the cron entry on 'root' [0], which is the user which is used to run the command here. In the provided traceback, the user is 'rabbitmq'. The charm has used the 'root' user since the 16.04 release of the charms so this charm must have some local modifications which break this.
A better option here would be to strip out the cron schedule by splitting the string and grabbing only the schedule pieces definition pieces (the first 5 entries).
[0] https:/ /github. com/openstack/ charm-rabbitmq- server/ blob/stable/ 21.04/files/ check_rabbitmq_ queues. py#L108