How to change Linux ulimit in shell provisioner to propagate to Docker installation?

I’m using the Packer tool to create an AWS AMI. I install Docker and a container as part of the provisioning. However, I also need to change the “ulimit -c unlimited” so that applications within a Docker container are able to produce a core file. We have scripts in the Docker container to trap signals and preserve the core file to a Docker volume.

From what I gather through experience, Packer logs into the AWS AMI in a single session and executes the provisioners in order. Since I’m working with Linux, I’m able to perform some “sudo” commands to modify the /etc/security/limits.conf file and remove any files in /etc/security/limits.d. This will allow changes in limits for the next login session, but not this current session.

I also need to install Docker and install the necessary containers. Since my current session has retained the limit values, the Docker installation will propagate the “soft” values to any container. In my case, the ulimit core is set to 0 for both hard and soft values. Docker will configure the containers with core limit of zero. Any application crashes within Docker will not produce core files.

Is there any way to configure the provisioners to change the ulimit settings for root access and session access? Alternatively, maybe there is a way to log off and log back on? Maybe as a last resort, reboot the AMI after one provisioner has changed the ulimits so that the next session login has the new values?

This may be a job for the user_data_file template option (amazon docs here) which runs before Packer actually connects. Normally we don’t bother with those for Linux instances, but they’re central to using Packer to provision Windows instances.

Reboots work fine – just use the shell provisioner to cause a reboot and set "expect_disconnect": true on that provisioner so Packer doesn’t freak out when it loses its ssh connection.

Thanks for the recommendation. However, that solution doesn’t seem to fix my problem. But, it did lead to other avenues of searching through Google.

I came upon this StackOverflow thread: The poster wanted to use user_data_file for some script level purposes, but the solution was to create a script and place it in /var/lib/cloud/scripts/per-boot or /var/lib/cloud/scripts/per-instance. My script just changes the ulimit -c unlimited and restarts the Docker daemon.
This got me around my difficulties.