Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cfn-hup in daemon mode doesn't work on any currently supported Python version, because of dependency on obsolete python-daemon version #392

Open
Aneurin opened this issue Jul 8, 2023 · 8 comments
Labels
bug keep Don't auto-close this

Comments

@Aneurin
Copy link

Aneurin commented Jul 8, 2023

aws-cfn-bootstrap requires python-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 launch cfn-hup in daemon mode:

Traceback (most recent call last):
  File "/usr/local/bin/cfn-hup", line 226, in <module>
    with daemon.DaemonContext(pidfile=pidfile.TimeoutPIDLockFile('/var/run/cfn-hup.pid', 300),
  File "/usr/local/lib/python3.10/dist-packages/daemon/daemon.py", line 280, in __init__
    detach_process = is_detach_process_context_required()
  File "/usr/local/lib/python3.10/dist-packages/daemon/daemon.py", line 801, in is_detach_process_context_required
    if is_process_started_by_init() or is_process_started_by_superserver():
  File "/usr/local/lib/python3.10/dist-packages/daemon/daemon.py", line 778, in is_process_started_by_superserver
    if is_socket(stdin_fd):
  File "/usr/local/lib/python3.10/dist-packages/daemon/daemon.py", line 743, in is_socket
    file_socket = socket.fromfd(fd, socket.AF_INET, socket.SOCK_RAW)
  File "/usr/lib/python3.10/socket.py", line 546, in fromfd
    return socket(family, type, proto, nfd)
  File "/usr/lib/python3.10/socket.py", line 232, in __init__
    _socket.socket.__init__(self, family, type, proto, fileno)
OSError: [Errno 88] Socket operation on non-socket

Ignoring the dependency error and forcing a newer python-daemon version seems to lead to cfn-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.

@mleziva
Copy link
Contributor

mleziva commented Aug 30, 2023

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

@mleziva
Copy link
Contributor

mleziva commented Sep 5, 2023

Hi @Aneurin, were you following the guidance from this post: https://repost.aws/knowledge-center/install-cloudformation-scripts?

@aneurin-price
Copy link

aneurin-price commented Sep 7, 2023

(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.

@guilleojeda
Copy link

@mleziva
Copy link
Contributor

mleziva commented Sep 25, 2023

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?

@aneurin-price
Copy link

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.

Copy link

Due to inactivity this issue will be closed in 7 days

@ericzbeard
Copy link
Contributor

I think this is the same issue as #411

@ericzbeard ericzbeard added the keep Don't auto-close this label May 20, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug keep Don't auto-close this
Projects
None yet
Development

No branches or pull requests

5 participants