Why is LANG environment variable set to en_US.UTF-8, when that locale is not installed?

1

In the Node.js 20.x runtime in AWS Lambda, the default value for LANG is set to en_US.UTF-8, even though this is not installed:

# locale -a
C
C.utf8
POSIX

Boost::filesystem crashes (intentionally) when the LANG environment variable specifies an invalid / not-installed locale, so the default behavior for any application that uses boost::filesystem is to crash. I think this is reasonable behavior from boost, but nevertheless poses an issue. Is this a bug / misconfiguration of the Amazon Node.js runtime? Or is there a reason for this locale to be specified as it is, and we should try to work around it?

asked 4 days ago27 views
1 Answer
1

Greeting

Hi msupport,

Thanks for bringing up this issue—it's a great example of how small environment settings can lead to unexpected challenges in serverless environments like AWS Lambda. I understand that your application depends on boost::filesystem, and its behavior is being disrupted by the default LANG setting in the Node.js 20.x runtime. Let’s resolve this and ensure your Lambda function runs smoothly! 😊


Clarifying the Issue

You’ve observed that the default LANG environment variable in the Node.js 20.x runtime on AWS Lambda is set to en_US.UTF-8, even though this locale isn’t installed. Running locale -a confirms that only C, C.utf8, and POSIX are available. As a result, boost::filesystem crashes when it encounters this invalid locale.

This behavior is not a bug in AWS but rather an unexpected default configuration. To avoid crashes, we need to align the LANG setting with an available locale or provide the missing locale if required. Let’s walk through a reliable and practical fix.


Why This Matters

AWS Lambda is often used for production workloads where reliability is critical. Configurations that lead to runtime crashes can disrupt operations and result in downtime. Addressing this issue ensures your application behaves predictably, regardless of runtime defaults, and minimizes the risk of production issues.


Key Terms

  • AWS Lambda Runtime: The environment in which Lambda functions execute, including pre-installed libraries, settings, and variables.
  • Locale: A setting that defines language and region-specific preferences for a program, such as text encoding and date formats.
  • Boost::filesystem: A library that provides portable, C++-standard filesystem manipulation; it depends on valid locales for error-free operation.

The Solution (Our Recipe)

Steps at a Glance:

  1. Update the LANG environment variable to a valid locale in your Lambda function.
  2. Rebuild or update your Lambda deployment package.
  3. Test the changes locally and in AWS.
  4. (Optional) Install additional locales if your application requires them.

Step-by-Step Guide:

  1. Modify the Environment Variable in Your Lambda Function:
    Use the AWS Lambda console or a deployment framework like AWS SAM or AWS CDK to override the default LANG variable. Set it to C.utf8, which is pre-installed and UTF-8 compatible.
    {
        "Variables": {
            "LANG": "C.utf8"
        }
    }
    For example, in AWS SAM, update your template.yaml file:
    Resources:
      MyFunction:
        Type: AWS::Serverless::Function
        Properties:
          Environment:
            Variables:
              LANG: C.utf8

  1. Rebuild or Update Your Lambda Deployment Package:
    If you are using a deployment package, ensure the updated LANG variable is included. Deploy the updated function to apply the changes.

  1. Test Locally and in AWS:
    Run your Lambda function locally (using tools like sam local invoke) and in AWS to confirm boost::filesystem no longer crashes. Test with inputs or conditions that previously caused the issue to ensure the fix works reliably.

  1. (Optional) Install Additional Locales:
    If your application requires a locale not pre-installed (like en_US.UTF-8), include it in your Lambda deployment package. For example, create a custom runtime layer or dynamically build the locale at runtime using:
    localedef -i en_US -f UTF-8 en_US.UTF-8

Closing Thoughts

This solution ensures your Lambda function behaves predictably while avoiding runtime crashes due to invalid locales. Adjusting the LANG variable to a valid, pre-installed locale like C.utf8 is a quick fix, but installing additional locales can be a viable option for applications with specific requirements.

Documentation Links:


Farewell

I hope this clears up the issue and helps you implement a solution seamlessly. Let me know if you encounter any hurdles or have further questions—happy to assist! 🚀😊


Cheers,

Aaron 😊

profile picture
answered 4 days ago
profile picture
EXPERT
reviewed 3 days ago

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