UPSTREAM FIX
magento2-39372: Ever growing var/locks directory with file based locking
Community fix magento2-39372 merged into magento/magento2 on 2025-04-02, released in 2.4.9; applies cleanly to 33 releases from 2.4.6 to 2.4.8-p5.
Fixes the ever growing var/locks directory with file based locking edited
- Pull request title
- When using file storage for the lock provider, we get an ever growing directory of files without any cleanup happening
- Pull request
- magento/magento2#39372
- Issues
- #39369 human
- Author
- @hostep
- Merged
- 2025-04-02
- Fixed in
- 2.4.9
- Reported on
- —
- Categories
- —
- Components
- magento/framework, magento/module-backend
Labels
- Area
- Framework
- Component
- Backend
- Priority
- P2
- Severity
- —
- Reported on (labels)
- 2.4.x
Issue
Title and steps come from the upstream issue and pull request.
Description
-
var/locks can contain up to millions of files after several months of running a Magento shopSteps to reproduce
1. Setup clean Magento with sample data
2. Make sure cronjobs are running
3. From the root of Magento, execute these commands:
5. Also create some orders
6. Look at the contents of the
Ideally you should look at a shop running for many months and where file based locking has been enabled, and inspect the directory that contains those lock files.
2. Make sure cronjobs are running
3. From the root of Magento, execute these commands:
$ mkdir "$(pwd)/var/locks" $ bin/magento setup:config:set --lock-provider=file --lock-file-path="$(pwd)/var/locks" $ bin/magento cache:enable $ bin/magento cache:flush4. Start visiting the frontend, please visit many different pages: homepage, category pages, product detail pages, ...
5. Also create some orders
6. Look at the contents of the
var/locks directoryIdeally you should look at a shop running for many months and where file based locking has been enabled, and inspect the directory that contains those lock files.
Expected result
-
var/locks directory should not overflow with an ever increasing amount of filesActual result
-
Example filenames:
So that's really bad. We need some kind of bugfix or cleanup mechanism to keep this under control.
var/locks can contain up to millions of files after several months of running a Magento shopExample filenames:
- BLOCK_833608638be7d42c9a8edf79b3516f6768babb37b07cb0c924ce1ede8c7b60f4-122217-final_price-EUR-20241114-1-0- - BLOCK_8c40abe5c67c542dd31f6ed0787db94f9b6c7add8c7eccb4aeff4dc1adb10d9d-122217 - BLOCK_833608638be7d42c9a8edf79b3516f6768babb37b07cb0c924ce1ede8c7b60f4-122209-final_price-EUR-20241114-1-0- - BLOCK_8c40abe5c67c542dd31f6ed0787db94f9b6c7add8c7eccb4aeff4dc1adb10d9d-122209 - BLOCK_833608638be7d42c9a8edf79b3516f6768babb37b07cb0c924ce1ede8c7b60f4-122213-final_price-EUR-20241114-1-0- - BLOCK_8c40abe5c67c542dd31f6ed0787db94f9b6c7add8c7eccb4aeff4dc1adb10d9d-122213 - BLOCK_833608638be7d42c9a8edf79b3516f6768babb37b07cb0c924ce1ede8c7b60f4-122194-final_price-EUR-20241114-1-0- - BLOCK_0dececc6f6ab51b0dc125a1d40b7c4fd8dac44300acc9927a9bbc923f0dc4b1d-122201-final_price-EUR-20241114-1-0- - BLOCK_fd38c4b3f09eb9f6357edad8fbb6fa37f447f4b29367471c1f63330cfd2e6041 - BLOCK_2b0ceeddda2b7376874129eed2893a53db19081fd2ff426fc9a63a3ad80125d3 - PLACE_ORDER_20194 - PLACE_ORDER_20197 - PLACE_ORDER_20199 - PLACE_ORDER_20201 - CRON_54ca823af2ab2bc8e0923548a617e1d9 - CRON_597b39571a8e2e02aa3da5b0b669058c - CRON_5d6e389185b7c7ff8ada1b70e5d5beec - CRON_5dc531608e6750f85d979bb963298bd3 - CRON_65418d1532274c42fbc28425e8b9b7f1 - CRON_65541ac6ef52e06c546be79471cf53ce - indexer_lock_category_product - SYSTEM_CONFIGWe had one project that had 3.5 million files in that directory, up to a point where the filesystem started complaining with errors like
Failed to open stream: No space left on device every time a lock file was needed (there was plenty of disk space, it's just that a directory can't handle that large amount of files in one directory). Another project had 1.9 million files and another had ~170.000 files.So that's really bad. We need some kind of bugfix or cleanup mechanism to keep this under control.
Taken from the upstream issue.
Code match per tag
Each tag was checked with git apply --check against that tag's files. A clean match means the change applies; it is not a test result. Tags that already contain the fix are marked.
| Line | Code match per tag | Tests |
|---|---|---|
| 2.4.6 | 2.4.6 clean 2.4.6-p1 clean 2.4.6-p2 clean 2.4.6-p3 clean 2.4.6-p4 clean 2.4.6-p5 clean 2.4.6-p6 clean 2.4.6-p7 clean 2.4.6-p8 clean 2.4.6-p9 clean 2.4.6-p10 clean 2.4.6-p11 clean 2.4.6-p12 clean 2.4.6-p13 clean 2.4.6-p14 clean 2.4.6-p15 clean | 2.4.6: no test data 2.4.6-p1: no test data 2.4.6-p2: no test data 2.4.6-p3: no test data 2.4.6-p4: no test data 2.4.6-p5: no test data 2.4.6-p6: no test data 2.4.6-p7: no test data 2.4.6-p8: no test data 2.4.6-p9: no test data 2.4.6-p10: no test data 2.4.6-p11: no test data 2.4.6-p12: no test data 2.4.6-p13: no test data 2.4.6-p14: no test data 2.4.6-p15: no test data |
| 2.4.7 | 2.4.7 clean 2.4.7-p1 clean 2.4.7-p2 clean 2.4.7-p3 clean 2.4.7-p4 clean 2.4.7-p5 clean 2.4.7-p6 clean 2.4.7-p7 clean 2.4.7-p8 clean 2.4.7-p9 clean 2.4.7-p10 clean | 2.4.7: no test data 2.4.7-p1: no test data 2.4.7-p2: no test data 2.4.7-p3: no test data 2.4.7-p4: no test data 2.4.7-p5: no test data 2.4.7-p6: no test data 2.4.7-p7: no test data 2.4.7-p8: no test data 2.4.7-p9: no test data 2.4.7-p10: test files do not apply to this releaseintegration: could not run before, could not run after |
| 2.4.8 | 2.4.8 clean 2.4.8-p1 clean 2.4.8-p2 clean 2.4.8-p3 clean 2.4.8-p4 clean 2.4.8-p5 clean | 2.4.8: no test data 2.4.8-p1: no test data 2.4.8-p2: no test data 2.4.8-p3: no test data 2.4.8-p4: no test data 2.4.8-p5: test could not run before the patch, passes afterintegration: could not run before, passes after |
| 2.4.9 | 2.4.9 conflictcontains the fix | 2.4.9: no test data |
Triage
Model @cf/cloudflare/clef. Probability this is a bug fix: 86.4%. Probability it is security relevant: 0.6%.
Show the model's answers and probabilities
| Question | Answer | Probabilities | Confidence |
|---|---|---|---|
| Change kind | bugfix | bugfix 76.0%, feature 19.7%, refactor 2.1%, tests_only 1.3%, dependency 0.5%, docs_only 0.4% | 54.0% |
| Area | framework | framework 91.7%, admin 3.1%, other 1.5% | 82.0% |
| Reported version | 2.4.7-p3 | 2.4.7-p3 27.3%, unspecified 11.1%, 2.4.7 10.9% | 9.9% |
| Scope | 0.96 of 2 | 1 54.0%, 0 25.2%, 2 20.8% | 9.8% |
| Risk | 0.40 of 2 | 0 65.7%, 1 28.7%, 2 5.5% | 27.6% |
| Worth backporting | 1.61 of 2 | 2 68.5%, 1 24.5%, 0 7.1% | 30.0% |
Download
For cweagans/composer-patches, choose a version below and download the bundle. Copy its magento2-39372/ folder into patches/composer/, merge composer.patches.json into composer.json, then run composer install. Test files are always removed; paths are relative to each package root, using the default -p1 level.
Bundle README (what the ZIP ships)
# magento2-39372 Community fix merged upstream into magento/magento2, adapted by magento.watch. This is not a patch published by Adobe. Pull request: https://github.com/magento/magento2/pull/39372 Issue: https://github.com/magento/magento2/issues/39369 Author: @hostep Source commit: b635942d9e077b34d1e72b76aa0262ab7f09f1ad Modifications: test files and documentation removed, paths rewritten relative to each Composer package. Licence: OSL-3.0 / AFL-3.0, as the original Magento Open Source code. Maintainer: Łukasz Bajsarowicz (@lbajsarowicz)
Licence: Magento Open Source code under OSL-3.0 and AFL-3.0. The bundle carries the original author, source commit and the list of modifications.
