### Author:  [@Ghan](https://meta.discourse.org/u/Ghan)
#### Post date: [December 23, 2020, 2:32am UTC](https://meta.discourse.org/t/docker-shm-size-option-in-app-yml/174067/1 "2020-12-23T02:32:44Z")
Would it be possible to make the shm\_size param an option in app.yml? I ran into this error today when trying to do a `vacuum analyze`:
`ERROR: could not resize shared memory segment`
It was trying to increase the shm usage to 1 GB and failed, as it’s only 512 MB out of the box. This param looks to be in the launcher script, but it might be nice to have this as an option (possibly commented out by default) in the .yml file.
---
### Author:  [@tgxworld](https://meta.discourse.org/u/tgxworld)
#### Post date: [December 23, 2020, 4:01am UTC](https://meta.discourse.org/t/docker-shm-size-option-in-app-yml/174067/2 "2020-12-23T04:01:44Z")
You can pass custom docker args to override the default we provide with `--docker-args`.
>
I believe it’ll look something like `./launcher start app --docker-args "--shm-size=1024m"`
---
### Author:  [@Ghan](https://meta.discourse.org/u/Ghan)
#### Post date: [December 23, 2020, 1:44pm UTC](https://meta.discourse.org/t/docker-shm-size-option-in-app-yml/174067/3 "2020-12-23T13:44:09Z")
This didn’t work when I tried it unfortunately. I think maybe the container needs to be rebuild to increase the size of the shared memory space? I had to change the value in the hard-coded areas in the launcher script and then rebuild the container for it to actually take effect.
This likely wouldn’t persist across updates/rebuilds either - you’d need to be manually changing it every time.
---
### Author:  [@tgxworld](https://meta.discourse.org/u/tgxworld)
#### Post date: [December 24, 2020, 1:03am UTC](https://meta.discourse.org/t/docker-shm-size-option-in-app-yml/174067/4 "2020-12-24T01:03:46Z")
What commands did you run? You’ll definitely have to rebuild the container for the `--shm-size` option to take effect.
---
### Author:  [@Ghan](https://meta.discourse.org/u/Ghan)
#### Post date: [December 24, 2020, 2:40am UTC](https://meta.discourse.org/t/docker-shm-size-option-in-app-yml/174067/5 "2020-12-24T02:40:48Z")
> [@tgxworld](#):
>
> What commands did you run?
All I did at first was stop the container, then run the launcher start command with that parameter. Then I manually edited the --shm-size params inside the launcher script itself and rebuilt the container. Then it adjusted the value correctly. If you override the param on the command line to rebuild the container, then won’t the change be lost if you perform an update/rebuild through the /admin/upgrade interface? That’s why I thought it might be best to make it a field in app.yml - then it would persist through rebuilds and code updates.
---
### Author:  [@tgxworld](https://meta.discourse.org/u/tgxworld)
#### Post date: [December 24, 2020, 5:46am UTC](https://meta.discourse.org/t/docker-shm-size-option-in-app-yml/174067/6 "2020-12-24T05:46:16Z")
> [@Ghan](#):
>
> That’s why I thought it might be best to make it a field in app.yml - then it would persist through rebuilds and code updates.
Hmm I can see this being useful. @sam What do you think about this?
---
### Author:  [@sam](https://meta.discourse.org/u/sam)
#### Post date: [December 29, 2020, 4:52am UTC](https://meta.discourse.org/t/docker-shm-size-option-in-app-yml/174067/7 "2020-12-29T04:52:24Z")
> [@Ghan](#):
>
> /admin/upgrade interface?
That never rebuilds the container though, so it is safe.
Don’t we already have this per:
>
`docker_args: ....` in your yaml.
---
### Author:  [@Ghan](https://meta.discourse.org/u/Ghan)
#### Post date: [December 29, 2020, 5:12am UTC](https://meta.discourse.org/t/docker-shm-size-option-in-app-yml/174067/8 "2020-12-29T05:12:40Z")
I’m not sure. Does that overwrite the launcher file itself? I see 3 places where the option is hardcoded:
>
>
>
---
### Author:  [@sam](https://meta.discourse.org/u/sam)
#### Post date: [December 29, 2020, 5:17am UTC](https://meta.discourse.org/t/docker-shm-size-option-in-app-yml/174067/9 "2020-12-29T05:17:04Z")
We should fix this then, but the fix is very very complicated bash script. Feel free to give this a shot.
Our docker args getting function should be responsible for shm-size. Handling user overrides and setting a default.
---
### Author:  [@neounix](https://meta.discourse.org/u/neounix)
#### Post date: [December 29, 2020, 5:39am UTC](https://meta.discourse.org/t/docker-shm-size-option-in-app-yml/174067/10 "2020-12-29T05:39:45Z")
> [@Ghan](#):
>
> I’m not sure. Does that overwrite the launcher file itself? I see 3 places where the option is hardcoded:
Hey @Ghan
In the meantime (for testing purposes, see caveat below), you can change this directly with docker after the container is built, as follows:
- Edit the `/var/lib/docker/containers/$CONTAINER_ID/hostconfig.json` file directly.
- For example, change the value for `ShmSize` in the file above.
- Stop and restart the container.
In our docker container hostconfig file, it looks like this:
```plaintext
"ShmSize":536870912,
```
HTH
Caveat: Some people have posted that you must make sure that docker service is stopped before you modify hostconfig.json (or the changes will be overwritten). However, I have not actually tested this. Obviously a `launcher` solution is better 🙂
---
### Author:  [@markersocial](https://meta.discourse.org/u/markersocial)
#### Post date: [November 29, 2024, 5:42pm UTC](https://meta.discourse.org/t/docker-shm-size-option-in-app-yml/174067/11 "2024-11-29T17:42:33Z")
Anyone know what the current solution for increasing shm\_size is?
Edit: Appears like it is still hardcoded.
Relevant thread:
> [@PG throws could not resize shared memory segment error](https://meta.discourse.org/t/pg-throws-could-not-resize-shared-memory-segment-error/84744):
>
> After upgrading (with ‘launcher rebuild app’ times two) to Postgres 10, we’ve started seeing errors like this in /logs: Failed to handle exception in exception app middleware : PG::DiskFull: ERROR: could not resize shared memory segment "/PostgreSQL.682207201" to 283432 bytes: No space left on device : SELECT "topics"."id" AS t0\_r0, "topics"."title" AS t0\_r1, "topics"."last\_posted\_at" AS t0\_r2, … Ideas? Looks like PG is unable to increase the size of a shared memory segment, can this be tuned …