Bug#379806: error is in ulimit option
Mario Lipinski wrote: Am Dienstag, den 25.07.2006, 22:34 +0200 schrieb Stefan Hornburg (Racke): in /etc/init.d/courier-imap ulimit -v $IMAP_ULIMITD is used instead of ulimit -d $IMAP_ULIMITD The purpose of that statement is to avoid memory hogs, why should the init script use ulimit -d ? OK. I should have read more carefully. /etc/courier/imapd says: ##NAME: IMAP_ULIMITD:0 # # IMAP_ULIMITD sets the maximum size of the data segment of the server # process. The value of IMAP_ULIMITD is simply passed to the ulimit -d # command (or ulimit -v). The argument to ulimi sets the upper limit on the # size of the data segment of the server process, in kilobytes. The default # value of 65536 sets a very generous limit of 64 megabytes, which should # be more than plenty for anyone. # # This feature is used as an additional safety check that should stop # any potential denial-of-service attacks that exploit any kind of # a memory leak to exhaust all the available memory on the server. # It is theoretically possible that obscenely huge folders will also # result in the server running out of memory when doing server-side # sorting (by my calculations you have to have at least 100,000 messages # in a single folder, for that to happen). IMAP_ULIMITD=65536 So -v should be OK. /etc/courier/courier-imap-ssl uses -d. So I thought the error was there. At least they should use the same ulimit option. I'll look into that. Bye Racke -- LinuXia Systems = http://www.linuxia.de/ Expert Interchange Consulting and System Administration ICDEVGROUP = http://www.icdevgroup.org/ Interchange Development Team -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#379806: error is in ulimit option
I think i finally found the error: in /etc/init.d/courier-imap ulimit -v $IMAP_ULIMITD is used instead of ulimit -d $IMAP_ULIMITD Mario signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Bug#379806: error is in ulimit option
Am Dienstag, den 25.07.2006, 22:34 +0200 schrieb Stefan Hornburg (Racke): in /etc/init.d/courier-imap ulimit -v $IMAP_ULIMITD is used instead of ulimit -d $IMAP_ULIMITD The purpose of that statement is to avoid memory hogs, why should the init script use ulimit -d ? OK. I should have read more carefully. /etc/courier/imapd says: ##NAME: IMAP_ULIMITD:0 # # IMAP_ULIMITD sets the maximum size of the data segment of the server # process. The value of IMAP_ULIMITD is simply passed to the ulimit -d # command (or ulimit -v). The argument to ulimi sets the upper limit on the # size of the data segment of the server process, in kilobytes. The default # value of 65536 sets a very generous limit of 64 megabytes, which should # be more than plenty for anyone. # # This feature is used as an additional safety check that should stop # any potential denial-of-service attacks that exploit any kind of # a memory leak to exhaust all the available memory on the server. # It is theoretically possible that obscenely huge folders will also # result in the server running out of memory when doing server-side # sorting (by my calculations you have to have at least 100,000 messages # in a single folder, for that to happen). IMAP_ULIMITD=65536 So -v should be OK. /etc/courier/courier-imap-ssl uses -d. So I thought the error was there. However since it works with -d the error has to do something with the effects of ulimit. (btw. in line 5 above is a typo: ulimi - ulimit) signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Bug#379806: error is in ulimit option
Mario Lipinski wrote: I think i finally found the error: in /etc/init.d/courier-imap ulimit -v $IMAP_ULIMITD is used instead of ulimit -d $IMAP_ULIMITD Mario The purpose of that statement is to avoid memory hogs, why should the init script use ulimit -d ? Bye Racke -- LinuXia Systems = http://www.linuxia.de/ Expert Interchange Consulting and System Administration ICDEVGROUP = http://www.icdevgroup.org/ Interchange Development Team -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
