Skip to content
This repository has been archived by the owner on Feb 26, 2020. It is now read-only.

Consider bumping up concurrent file limit #7

Open
tylersticka opened this issue Aug 28, 2014 · 12 comments
Open

Consider bumping up concurrent file limit #7

tylersticka opened this issue Aug 28, 2014 · 12 comments
Labels

Comments

@tylersticka
Copy link
Member

A common issue I think most of the folks on the team have run into at one time or another are those irritating ENOINT errors when OS X exceeds the 256-file limit.

I'm not sure if Boxen allows us to add custom stuff to the .profile by default, but this line seems to have done the trick in mine:

ulimit -n 4096
@lharding lharding added the bug label Aug 29, 2014
@lyzadanger
Copy link
Contributor

Note that approach is session-based and will not persist, so if we want to boxen this we need to take care.

Is this something typically added to peoples dotfiles, @tylersticka ? Is that how people maintain it?

@tylersticka
Copy link
Member Author

I have this in ~/.profile (right below the boxen line):

#   Increase concurrent file limits (256 is default)
#   ------------------------------------------------------------

ulimit -n 8192

And I've never had to mess with it again. But when I pass that along to my teammates (I think @erikjung was one of them) they said that wasn't enough for them. So I'm not sure why I'm special and able to run the exact same project and never have to set the limit per session...

@lyzadanger
Copy link
Contributor

@tylersticka @erikjung @lharding It seems like this is something we've run into more lately. Do any of you have thoughts? Should we be managing ulimit with boxen? @lharding you seem like the most experienced in this area. Any ideas for sane defaults?

@erikjung
Copy link
Contributor

@tylersticka I actually never added it to my .profile that way. I just have an alias of ulimit10k that sets it to 10000, which I invoke whenever needed. I only have problems with it every few months, almost always in the form of vague errors in Gulp or Grunt tasks. I suppose we can all try adding the command in this way and see if the value persists?

@tylersticka
Copy link
Member Author

@erikjung It is no longer in my profile since I switched to the dotfiles setup, though I can't help but notice that I seemed to be largely immune to most of these ulimit troubles until I removed it... hrmm...

@lyzadanger
Copy link
Contributor

Hi, @tylersticka!

This one does come up now and again, doesn't it. Do you have a preference of how we might manage this strategically?

Right now our common set of dotfiles (which you get if you don't manage your own dotfiles, https://github.com/cloudfour/cloudfour-boxen/tree/master/modules/cloudfour_potions/files/dotfiles ) doesn't manage an actual profile of any sort (nor do I necessarily think we should; seems a little dangerous).

Is this something you've added to your own dotfiles setup? Is it something you'd like to template so other people can use? Do you have a preferred approach? Let me know how I can help.

@erikjung
Copy link
Contributor

@lyzadanger @tylersticka

For OS X modifications, what about adding some of the classes provided by https://github.com/boxen/puppet-osx

And then for any other random commands we need to run, we write our own extensions, for example:

class osx::finder::unhide_library {
  $home = "/Users/${::boxen_user}"

  exec { 'Unhide ~/Library':
    command => "chflags nohidden ${home}/Library",
    onlyif  => "ls -Ol ${home} | grep Library | grep hidden";
  }
}

@lyzadanger
Copy link
Contributor

@erikjung OK, maybe, but I don't know that that module would allow us to mess with concurrent file limits?

@erikjung
Copy link
Contributor

@lyzadanger I assumed that because it allows any command to be executed, we could do...anything?

(I don't know if this would work)

class osx::misc::increase_ulimit {
  exec { "Increase concurrent open file limit":
    command => "ulimit -n 10000"
  }
}

@lyzadanger
Copy link
Contributor

@erikjung But I'm unclear as to the context of that process. Does it run when boxen executes? I don't imagine it would run every time you open a new Terminal (a la *profile files).

@erikjung
Copy link
Contributor

@lyzadanger Yeah, I have no idea. I only mentioned the puppet-osx solution because this issue seemed to fall into the category of how should we use Boxen to apply commonly needed setting overrides?

Maybe the simplest thing to do for now is just tell everyone to add the command plus an alias command to their .profile. Maybe it will stick, maybe it won't. They can use the alias (lets say filesplz) to invoke it manually.

@tylersticka
Copy link
Member Author

Back in January, that addition to .profile worked flawlessly.

Then OS X updated and it stopped working for me. The command would work if you ran it manually, but not as part of any of my bash or profile dotfiles. So I decided to ape what @erikjung was doing in his dotfiles and create an alias for that command.

This is probably the most common head-scratchingly mysterious issue that comes up for the team... unfortunately in the months since creating the issue, no obvious remedy exists that I'm aware of. If there were some sort of system-level tweak that would remedy it, I'd love it. But absent that, I'm fine just running ulimit10 via my dotfiles.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

4 participants