Running into an "interesting" issue with AMI generation in AWS. We have a set of layered automations (AMIgenerator and spel) we use for generating AMIs. We generate "day-to-day" and "recovery" AMIs for both RHEL and CentOS 7 (both tools are used for creating the day-to-days and just the AMIgenerator for the recovery AMIs).

Our "day-to-day" AMIs are fine across regions for both RHEL/CentOS. Our "recovery" AMIs are also fine across regions for CentOS but not RHEL 7. Specifically, when trying to run systemctl daemon-reexec (used by spel when generating "day-to-day" AMIs from the "recovery" AMIs), the action fails with the error

Error getting authority: Error initializing authority: Could not connect: Connection refused (g-io-error-quark, 39).

Googling around there's a definite paucity of hits on the g-io-error-quark and no hits when you look for the 39 sub-code. Near as I can surmise, systemd is either dead(??) or is sufficiently jacked-up that it's refusing to listen for control messages. However, that's as much as I can surmise.

Also, as noted previously, this only happens for Red Hat but not CentOS and only happens in the context of attempting to pivot-root with the recovery AMI. On the face, the recovery AMI seems to function about as one would normally expect.