Re: [Dovecot] v2.1.rc1 released
El 24/11/11 21:35, Miguel Tormo escribió: El Jueves, 24 de Noviembre de 2011 20:25:47 Timo Sirainen escribió: I'm not sure if changing /etc/security/limits.conf helps. It's probably only used by PAM when user logs in, so if Dovecot is started in system bootup it's unlikely to have been even read yet. Also I think some OSes override the limits in /etc/init.d/ scripts. Of course, I could be completely wrong in all of the above, I haven't really tested any of it Well actually this is tricky, I'm not sure if it would work after a system boot, but I'm sure it works after a reboot of the service. It is also true what you say that some OSes override the limits in the /etc/init.d/ scripts, for example issuing an 'ulimit -n 4096' (if using bash) before dropping privileges (that should be inherited, but if privileges are dropped using su or something that uses PAM, then the /etc/security/limits.conf file comes into play again). I tested this intensively some time ago, and Timo is right -as usual :) -: modifications in limits.conf are only relevant after a login. This means that they are not enforced at system boot, but they are if you reboot the service by hand (because you have already logged in). The permanent solution is, as Noel Butler has pointed, modifying the startup script and using ulimit before actually starting dovecot. HTH
Re: [Dovecot] v2.1.rc1 released
On Thu, Nov 24, 2011 at 09:25:47PM +0200, Timo Sirainen wrote: I'm not sure if changing /etc/security/limits.conf helps. It's probably only used by PAM when user logs in, so if Dovecot is started in system bootup it's unlikely to have been even read yet. Also I think some OSes override the limits in /etc/init.d/ scripts. Of course, I could be completely wrong in all of the above, I haven't really tested any of it :) The OP was running Centos, and the Red Hat way of increasing nofile for services is to add the ulimit setting to /etc/sysconfig/dovecot: ulimit -n 32768 This is what we use, and it survives dovecot upgrades (since this is tagged as a configfile in RPM, not as script that will be overwritten on upgrades). -jf
Re: [Dovecot] v2.1.rc1 released
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Timo Sirainen said the following on 24/11/11 01:46:
http://dovecot.org/releases/2.1/rc/dovecot-2.1.rc1.tar.gz
Works as advertised.
I noticed this warining:
Warning: fd limit (ulimit -n) is lower than required under max. load (1024
4096), because of service auth { client_limit }
What does exactly means?
The server we are talking about is my home server, a CentOS/64 with a dozen of
mailboxes.
Ciao,
luigi
- --
/
+--[Luigi Rosa]--
\
Computers make excellent and efficient servants,
but I have no wish to serve under them.
Captain, a starship also runs on loyalty to one man.
And nothing can replace it or him.
--Spock, The Ultimate Computer
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk7OhxwACgkQ3kWu7Tfl6ZSJ0gCeIaS5ksyVHY3O9qOSCEyWUH2V
By8AoMbUNSHBBc4102vScrozTOOkOeo+
=AZaL
-END PGP SIGNATURE-
Re: [Dovecot] v2.1.rc1 released
El Jueves, 24 de Noviembre de 2011 19:04:12 Luigi Rosa escribió:
Timo Sirainen said the following on 24/11/11 01:46:
http://dovecot.org/releases/2.1/rc/dovecot-2.1.rc1.tar.gz
Works as advertised.
I noticed this warining:
Warning: fd limit (ulimit -n) is lower than required under max. load (1024
4096), because of service auth { client_limit }
What does exactly means?
The server we are talking about is my home server, a CentOS/64 with a dozen of
mailboxes.
The fd limit is the maximum number of concurrently open file descriptors per
process. It can be configured on a per-user basis.
You can check the actual value running 'ulimit -n'. It can be increased up to
the value set in /proc/sys/fs/file-max. You can set it editing
/etc/security/limits.conf.
What the above comment means is that under max load the auth service could need
up to 4096 file descriptors open, that's more than the default in most linux
systems (1024).
However, in your case with just a dozen of mailboxes I don't think you'll need
to change it.
Re: [Dovecot] v2.1.rc1 released
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Miguel Tormo said the following on 24/11/11 19:23: The fd limit is the maximum number of concurrently open file descriptors per process. It can be configured on a per-user basis. You can check the actual value running 'ulimit -n'. It can be increased up to the value set in /proc/sys/fs/file-max. You can set it editing /etc/security/limits.conf. What the above comment means is that under max load the auth service could need up to 4096 file descriptors open, that's more than the default in most linux systems (1024). However, in your case with just a dozen of mailboxes I don't think you'll need to change it. Thank you for the explaination. Ciao, luigi - -- / +--[Luigi Rosa]-- \ A woman was in love with fourteen soldiers. It was clearly platoonic. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk7OjRUACgkQ3kWu7Tfl6ZQXAwCgyD6LAUYQX7/x1PIFda5CoFjx IYsAniqFYvdk6y982XjvWsWc4G5t9zEC =70Em -END PGP SIGNATURE-
Re: [Dovecot] v2.1.rc1 released
On Thu, 2011-11-24 at 19:23 +0100, Miguel Tormo wrote: The fd limit is the maximum number of concurrently open file descriptors per process. It can be configured on a per-user basis. You can check the actual value running 'ulimit -n'. It can be increased up to the value set in /proc/sys/fs/file-max. You can set it editing /etc/security/limits.conf. I'm not sure if changing /etc/security/limits.conf helps. It's probably only used by PAM when user logs in, so if Dovecot is started in system bootup it's unlikely to have been even read yet. Also I think some OSes override the limits in /etc/init.d/ scripts. Of course, I could be completely wrong in all of the above, I haven't really tested any of it :) What the above comment means is that under max load the auth service could need up to 4096 file descriptors open, that's more than the default in most linux systems (1024). I wonder if there's a good reason for why auth default should be that high. Probably in earlier times imap/pop3 processes just weren't disconnecting early enough from auth. So I guess I'll just drop it back to default and this warning would go away in most systems. I had started to get a little bit annoyed at that warning myself also.
Re: [Dovecot] v2.1.rc1 released
El Jueves, 24 de Noviembre de 2011 20:25:47 Timo Sirainen escribió: I'm not sure if changing /etc/security/limits.conf helps. It's probably only used by PAM when user logs in, so if Dovecot is started in system bootup it's unlikely to have been even read yet. Also I think some OSes override the limits in /etc/init.d/ scripts. Of course, I could be completely wrong in all of the above, I haven't really tested any of it Well actually this is tricky, I'm not sure if it would work after a system boot, but I'm sure it works after a reboot of the service. It is also true what you say that some OSes override the limits in the /etc/init.d/ scripts, for example issuing an 'ulimit -n 4096' (if using bash) before dropping privileges (that should be inherited, but if privileges are dropped using su or something that uses PAM, then the /etc/security/limits.conf file comes into play again). Another permanent way between reboots that I just googled is changing this line of includes/linux/fs.h: #define INR_OPEN 1024 /* Initial setting for nfile rlimits */ and recompile the kernel :P.
Re: [Dovecot] v2.1.rc1 released
On Thu, 2011-11-24 at 21:35 +0100, Miguel Tormo wrote: El Jueves, 24 de Noviembre de 2011 20:25:47 Timo Sirainen escribió: I'm not sure if changing /etc/security/limits.conf helps. It's probably only used by PAM when user logs in, so if Dovecot is started in system bootup it's unlikely to have been even read yet. Also I think some OSes override the limits in /etc/init.d/ scripts. Of course, I could be completely wrong in all of the above, I haven't really tested any of it Well actually this is tricky, I'm not sure if it would work after a system boot, but I'm sure it works after a reboot of the service. It is also true what you say that some OSes override the limits in the /etc/init.d/ scripts, for example issuing an 'ulimit -n 4096' (if using bash) before dropping privileges (that should be inherited, but if privileges are dropped using su or something that uses PAM, then the /etc/security/limits.conf file comes into play again). much simpler way without rebuilding is as Timo suggested, just pick your value #!/bin/sh # Start/stop dovecot. ulimit -n 16384 ... Be careful, building in kernel based higher limits means /every/ service and can lead to DoS, this way limits dovecot to 16384, but keeps other stuff like mysql at 4096, and everything else at 1024, bit safer. signature.asc Description: This is a digitally signed message part
