Open Aneurin opened 1 year ago
Hi Aneurin, thanks for bringing this to our attention. This repo just supports the sample templates. I will see if I can find the correct team that supports aws-cfn-bootstrap
Hi @Aneurin, were you following the guidance from this post: https://repost.aws/knowledge-center/install-cloudformation-scripts?
(Originally filed under my personal account, but this is my work account)
Apologies, it's been some time and it looks like I no longer have my notes from this, but I believe I found some documentation that took me to https://github.com/awslabs/aws-cloudformation-templates/blob/master/aws/solutions/OperatingSystems/Ubuntu22.04_cfn-hup.yaml - it could well have been that page although it doesn't look hugely familiar.
Ultimately I just ended up doing
/lib/systemd/system/cfn-hup.service:
content: !Sub |
[Unit]
Description=cfn-hup
[Service]
Type=oneshot
ExecStart=/usr/local/bin/cfn-hup -c /etc/cfn --no-daemon
[Install]
WantedBy=multi-user.target
mode: '000400'
owner: root
group: root
/lib/systemd/system/cfn-hup.timer:
content: !Sub |
[Unit]
Description=Run cfn-hup every minute
[Timer]
OnCalendar=*-*-* *:*:00
[Install]
WantedBy=timers.target
mode: '000400'
owner: root
group: root
which is inelegant but gets the job done.
I'm guessing what you're really looking for is trivial steps to reproduction - I have some vague recollection of eventually realising that it only crashed after restarting or something like that, and thus the template could appear to work correctly at first run. I'm a bit swamped but I can try to take a look next week if I get the time.
I'm experiencing the same problem. @aneurin-price maybe you were led to this repo from the official docs? https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Install-CloudWatch-Agent-New-Instances-CloudFormation.html#installing-CloudWatch-Agent-using-CloudFormation-Templates-inline That's how I got here
Looks like the latest version of aws-cfn-bootstrap does support newer versions of python, but the S3 account link to the latest version is not actually pointing to the latest version.
aws-cfn-bootstrap documentation (to access links to the latest versions): https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/releasehistory-aws-cfn-bootstrap.html
Incorrect latest link: https://s3.amazonaws.com/cloudformation-examples/aws-cfn-bootstrap-latest.tar.gz => points to version 1.4 which is not the latest
However the py3 latest link points to a version that is closer to the latest: https://s3.amazonaws.com/cloudformation-examples/aws-cfn-bootstrap-py3-latest.tar.gz
Can you verify if the issue is fixed when using a newer version?
That's definitely the version with the issue, because its setup.py
requires python-daemon>=2.1,<2.2
.
I've just spent an hour or so trying to replicate this again but it's tough because it originally came up in a large stack with a lot of dependencies and I've not yet been able to minimise it. I've also not had any success in using https://github.com/awslabs/aws-cloudformation-templates/blob/master/aws/solutions/OperatingSystems/Ubuntu22.04_cfn-hup.yaml as a starting point, because that template doesn't work. Even after fixing the obvious copy/paste errors in it I still haven't been able to get anything that successfully triggers cfn-hup
after a stack update, and I'm not certain if it's something to do with this problem or if I've just made a mistake. It's unfortunate that there aren't any working minimal examples to start from.
I have to go away for a bit but I can probably find a couple of hours the week after next to try properly debugging this by paring down a known-working stack, and then switching it back into daemon mode.
Due to inactivity this issue will be closed in 7 days
I think this is the same issue as #411
aws-cfn-bootstrap
requirespython-daemon<2.2
, but version 2.2.4 (from 2019) is the oldest version that supports Python 3.8+. Thus, any OS with a current version of Python (eg 3.10 in Ubuntu 22.04) will get the following error when attempting to launchcfn-hup
in daemon mode:Ignoring the dependency error and forcing a newer
python-daemon
version seems to lead tocfn-hup
silently failing, which I've not investigated further, so currently the best workaround I know of is to run it with--no-daemon
in a cronjob or systemd timer.