On a production cloud, sometime after we migrated hosts from Xenial to Bionic, we decided to remove an application for which filebeat was a subordinate.
Unfortunately, the stop hook failed. They were repeatedly failing on this command: ['apt-get', '--assume-yes', 'purge', 'filebeat']
Looking at logs, it appears that earlier they failed on this command: ['dpkg-query', '--show', '--showformat=${Version}\n', 'filebeat']
The issue was root-caused to the install_sources apt line being commented out as a side effect of the Xenial to Bionic upgrade, and could be mitigated by a post-series-upgrade hook to re-enable or re-write the apt config line.
This was worked around by finding the apt line in question, commenting it out, and then running "apt-get update". This allowed the filebeat units to clear out on their next attempt to rerun the stop hook.
On a production cloud, sometime after we migrated hosts from Xenial to Bionic, we decided to remove an application for which filebeat was a subordinate.
Unfortunately, the stop hook failed. They were repeatedly failing on this command: ['apt-get', '--assume-yes', 'purge', 'filebeat']
Looking at logs, it appears that earlier they failed on this command: ['dpkg-query', '--show', '--showformat=${Version}\n', 'filebeat']
The issue was root-caused to the install_sources apt line being commented out as a side effect of the Xenial to Bionic upgrade, and could be mitigated by a post-series-upgrade hook to re-enable or re-write the apt config line.
This was worked around by finding the apt line in question, commenting it out, and then running "apt-get update". This allowed the filebeat units to clear out on their next attempt to rerun the stop hook.