Amazon Linux 2 on Beanstalk isn't installing SQSD and prevents cron.yml from working

0

We're on solution stack "64bit Amazon Linux 2 v3.3.13 running PHP 7.4" the worker server is spinning up, unpacking the "platform-engine.zip" and when it comes to setting up SQSD:

May 23 12:45:01 ip-172-31-12-195 su: (to sqsd) root on none
May 23 12:45:10 ip-172-31-12-195 aws-sqsd-monitor: restarting aws-sqsd...
May 23 12:45:10 ip-172-31-12-195 systemd: Starting (null)...
May 23 12:45:10 ip-172-31-12-195 su: (to sqsd) root on none
May 23 12:45:10 ip-172-31-12-195 systemd: Created slice User Slice of sqsd.
May 23 12:45:10 ip-172-31-12-195 systemd: Started Session c2 of user sqsd.
May 23 12:45:10 ip-172-31-12-195 aws-sqsd: Version 2 of the Ruby SDK will enter maintenance mode as of November 20, 2020. To continue receiving service updates and new features, please upgrade to Version 3. More information can be found here: https://aws.amazon.com/blogs/developer/deprecation-schedule-for-aws-sdk-for-ruby-v2/
May 23 12:45:13 ip-172-31-12-195 aws-sqsd: Cannot load config file. No such file or directory: "/etc/aws-sqsd.d/default.yaml" - (AWS::EB::SQSD::FatalError)
May 23 12:45:13 ip-172-31-12-195 systemd: aws-sqsd.service: control process exited, code=exited status=1
May 23 12:45:13 ip-172-31-12-195 systemd: Failed to start (null).
May 23 12:45:13 ip-172-31-12-195 systemd: Unit aws-sqsd.service entered failed state.
May 23 12:45:13 ip-172-31-12-195 systemd: aws-sqsd.service failed.
May 23 12:45:13 ip-172-31-12-195 systemd: Removed slice User Slice of sqsd.

I can't find anything online about this, so some help would be greatly appreciated.

1 Answer
0

Hello,

The error "aws-sqsd: Cannot load config file. No such file or directory: "/etc/aws-sqsd.d/default.yaml" - (AWS::EB::SQSD::FatalError)" was thrown because EB could not find the configuration file for the SQS queue and this file is updated based on your environment configuration.

A potential reason why the sqsd failed to start could be memory issue. Could you verify your instance type and try a deployment using a larger instance type such as t4g.xlarge. Could you also verify if an initial deployment on a fresh instance works vs a deployment on an instance that was already deployed to. An initial deployment may be successful contrary to a subsequent deployment because when a new instance is launched and used, complete memory capacity is available for the SQSD daemon.

I found some third party related issues 1 and 2 that may be of help.

AWS
answered 2 years ago
  • It wasn't a memory issue. It looks like CloudFormation isn't working with the current Solution Stack.

    The process isn't starting since the default.yaml is missing, and it's missing because the command to get it isn't functional?

    I ran it (sudo /opt/elasticbeanstalk/bin/get-config --output YAML meta -k sqsdconfig) manually on a lower environment for testing purposes and put the cleaned-up contents into the default.yaml and the service spun up no problem.

    Current CF runs says: getMetadata.py --yaml --path AWS::ElasticBeanstalk::Ext._SqsDaemonConfigFileContent | sed -e "s/'//g" -e 's/"//g' > /etc/aws-sqsd.d/default.yaml

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Guidelines for Answering Questions