On Tue, 18 Nov 2014, Gaudenz Steinlin wrote: > > Hi > > Dmitry Smirnov <[email protected]> writes: > > > On Mon, 17 Nov 2014 09:18:50 Sage Weil wrote: > >> Also, > >> > >> +LimitNOFILE=32768 > >> > >> is still going to be problematic as large clusters need to adjust that > >> value up. Need to figure out how to make it tunable... maybe just by > >> using a dedicated 'ceph' user and adjusting it in /etc/security/limit.d/* > >> ? > > > > Due to systemd .service file limitations it is hard to make it tunable > > since > > LimitNOFILE do not take variables. What are the disadvantages of hardcoding > > it > > to higher value? I'm not sure what's best to do... > > I investigated this a bit. It's possible to have a [email protected] > directory with additional configuration options in it. So it's possible > to just change this setting without overriding the whole service unit > file. But I have found no way to read the vaule from ceph.conf like the > sysv init script does. Someone on #debian-systemd confirmed that this is > not possible. > > Is the value in ceph.conf used for anything else than the init script? > If it's only used in the init script I'm not sure if it really belongs > there.
Yeah, agreed. > LimitNOFILE=infinity causes this to be set to the maximum possible value > (hard limit). Maybe we can just use that. If more than the hard limit is > needed, the pam_limits configuration has to be adjusted anyway (also for > sysv). Do you see any downsides to setting this value as high as > possible for everyone? That is probably the way to go for now,yeah! In the future, I think pam (for /etc/security/limits.d .. that's wht you mean, right?) is the 'right' way to approach this (i.e., not explicitly ceph's problem). sage -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
