This repository has been archived by the owner on Mar 21, 2018. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 84
Chef/Berks creating tons of folders in /tmp directory. Regression? #324
Comments
Hello, Has somebody looked into this? I'm having a similar issue but I don't even have ridley in my environment drwx------ 2 user user 4096 3月 18 09:47 2016 d20160318-6902-rplpd8 drwx------ 2 user user 4096 3月 18 09:43 2016 d20160318-5841-wbsuzy drwx------ 2 user user 4096 3月 18 09:38 2016 d20160318-4352-1ond4fx ... $ knife --version Chef: 12.6.0 $ ruby --version ruby 2.1.6p336 (2015-04-13 revision 50298) [x86_64-linux] $ gem list | grep ridley $ gem list | grep chef chef (12.6.0, 12.4.1) chef-config (12.6.0, 12.5.1, 12.4.1) chef-zero (4.4.0, 4.2.3) cheffish (1.6.0) |
@AnalogJ is this still occurring? (sorry it's been a year, we're trying to get back in the game with berkshelf) |
not 100% sure, we threw in a cronjob to delete the folders created by berkshelf in our tmp folder. |
thanks! |
Hey @thommay
|
Any update on this? We're still seeing this..
|
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
I'm creating a new issue for visibility:
This may be a regression of the issue fixed in #262
Basically the issue is that any time knife/berks commands are run, we're seeing a ton of new folders being created in the /tmp folder (in the same format as the issue referenced above)
Here's the debugging info that @jsirex provided in the berkshelf/berkshelf#1069 issue. Note, I wiped out the /tmp folder and then ran our script once and the following files were created. Our script uses the ridley gem, executes berks multiple times and also calls knife.
Chef version information:
Ruby & Gem version info
I didnt provide the Berksfile/Berksfile.lock/knife.rb nor full Gemlist but I can if needed.
This is a big deal because in CentOS there seems to be a limit of ~32000 subfolders in a single directory.
Our CI environment was completely clobbered as nothing could write to the /tmp folder anymore. We've noticed that we can hit that limit in as little as 2 days.
The text was updated successfully, but these errors were encountered: