Andy

Hmm, actually I realised the STAMPFILE is not deleted even when not using dry run, when the handler is anything but 'remove', since the 'remove' handler is the only one...

Hi and thanks for the reply. Nope, with --verbose, I do not get anything apart from the initial list of what it is watching ([xnotify] Watching: ...). That list only...

Hi. Yep, it seems to: ``` ak@rhino:~$ inotifywait -m /home/ak/ Setting up watches. Watches established. /home/ak/ OPEN,ISDIR /home/ak/ ACCESS,ISDIR /home/ak/ ACCESS,ISDIR /home/ak/ CLOSE_NOWRITE,CLOSE,ISDIR /home/ak/ CREATE jhdks /home/ak/ OPEN jhdks /home/ak/...

I would be interested to know how the wrapping logic works when piping or redirecting: ``` $ awless list certificates | ARN ▲ | NAME | |-------------------------------------------------------------------------------------|----------------------| | arn:aws:acm:us-east-1:111111111111:certificate/aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee |...

> Slightly better wrapper script: > > ```shell > #!/bin/sh > /full/path/to/fswatch -x "$@" | sed ' > s/ IsDir// > s/ PlatformSpecific// > s/\( [A-Z][a-zA-Z]\+\)\+$/ XXX_KEEP_THIS_LINE_XXX/ > / XXX_KEEP_THIS_LINE_XXX$/!d...

@denilsonsa thanks. Did you use any other tool instead?

+1 from me

We're affected by this, using Debian 12 AWS EC2 AMIs. As well as agreeing that it is somehow IPv6 related, it also seems to only cause resolution failures for CNAMEs....

Thanks @nmeyerhans, that's good to know. I've edited my post now I realise that my workaround leaves you with no working /etc/resolv.conf after a reboot. Oops. 🤡

If it helps anyone, here's a link to the working Windows version: https://amazoncloudwatch-agent.s3.amazonaws.com/windows/amd64/1.247354.0b251981/amazon-cloudwatch-agent.msi