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
