0

I have recently setup exim version 4.86.1 running as a Cygwin service in Windows Server 2008 R2. If I send a single email at a time, it works fine. However, if I try and send 10 emails, each immediately after the other using a script, maybe only one or two emails will work. Adding a 5 second pause between emails also works.

In the exim_panic.log file, each failure is due to the following type of error:

2016-06-07 04:09:00 O8DPZ0-000708-7G Cannot lock /var/spool/exim/input/0/O8DPZ0-000708-7G-D (11): Resource temporarily unavailable

Meanwhile, the /var/spool/exim/input directory contains a bunch of zero sized files with names matching that in the error message above (i.e., O8DPZ0-000708-7G-D). These messages are not in the queue, since exim -bpc returns zero, and exim isn't retrying to send the emails.

mpeac
  • 101
  • 2
  • “You should tell us what you found/tried in your research and why it didn’t meet your needs”. See https://serverfault.com/help/how-to-ask – Anthony Geoghegan Jun 07 '16 at 08:39
  • I've tried different settings for the `CYGWIN` environment variable, and running under different user accounts, etc, but none of that seems to make much difference. The thing is, it works fine - so long as I don't hammer it, so the configuration of exim isn't incorrect. – mpeac Jun 07 '16 at 11:00

1 Answers1

1

The Resource temporarily unavailable error typically means you’ve hit a system or process resource limit such as available memory, the number of allowed user processes, the number of files a user can have open at any one time. You can get this error when starting a new process, opening a new file or when a currently running process asks the kernel for more memory.

Some of these limits are user limits which can be set using the ulimit command. Running the ulimit -a command will show what user limits are currently set to, e.g.,

$ ulimit -a

core file size          (blocks, -c) unlimited
data seg size           (kbytes, -d) unlimited
file size               (blocks, -f) unlimited
open files                      (-n) 256
pipe size            (512 bytes, -p) 8
stack size              (kbytes, -s) 2036
cpu time               (seconds, -t) unlimited
max user processes              (-u) 256
virtual memory          (kbytes, -v) unlimited

From the error message it sounds like that your problem might be due to running out of file descriptors. It might be worth checking what file descriptors are open by running

ls -l /proc/<PID>/fd

Cygwin specific

Similar problems can also be caused by one of the Big List Of Dodgy Apps (a list of applications that interfere with the normal working of Cygwin by intrusively injecting themselves in the system call chain).

I’ve never used Exim so I don’t know if it forks many child processes while it’s operating but Fork failures may also be an issue; they are documented in the Cygwin FAQ: How do I fix fork() failures?. Sometimes installed libraries are not updated properly and they have to be updated using the Cygwin setup.exe, or by running rebaseall. See

Finally, I used to receive a lot of Resource temporarily unavailable messages when I was running 32-bit Cygwin. After upgrading to 64-bit, these mostly went away.

Anthony Geoghegan
  • 2,875
  • 1
  • 24
  • 34
  • Thanks a lot for the suggestions, Anthony. I tried `rebaseall` - no change. I increased the number of open files permitted with `ulimit -n`, but this appears to just affect the current shell, while `exim` is run as a windows service via `cygrunsrv`. Under linux, it appears that this can be set system wide via `/etc/security/limits.conf`, but this file doesn't appear to also be in Cygwin. Any ideas? – mpeac Jun 07 '16 at 21:52
  • @mpeac I'm afraid I've no idea how to change the file descriptor limit in Cygwin. When I think back, most of the time I got the error were due to running out of memory when using git and colleagues had committed large files. Upgrading to 64-bit Cygwin helped with that. – Anthony Geoghegan Jun 07 '16 at 22:25
  • 1
    I'm already using 64 bit Cygwin. In the end, I've ditched `exim` and will go with another solution. – mpeac Jun 09 '16 at 00:29