I noticed in liblock/lockdaemon.c that "99" is hardcoded as a file descriptor. I understand that it was important to dup2 the original lockfd to something other than file descriptor "3" which has special meaning for filters using the courierfilter API. I'm guessing that "99" was chosen because it's unlikely that a filter would open 100 file descriptors before calling ll_start_daemon(). However, "99" may not always be available as a file descriptor due to resource limits imposed by the system. SUSv3 says that "OPEN_MAX" is the maximum number of files that one process can have open at any one time. I've attached a patch that uses (OPEN_MAX - 1) instead of 99.

Cheers,

-- Johnny Lam

$NetBSD: patch-aw,v 1.1 2007/09/23 11:42:44 jlam Exp $

--- liblock/lockdaemon.c.orig 2007-05-04 23:04:41.000000000 -0400 +++ liblock/lockdaemon.c @@ -8,4 +8,5 @@ #include <stdio.h> #include <signal.h> +#include <limits.h> #include <stdlib.h> #include <string.h> @@ -31,4 +32,8 @@ #endif

+#ifndef OPEN_MAX +#define OPEN_MAX 64 +#endif + #define exit(_a_) _exit(_a_)

@@ -146,5 +151,5 @@ int lockfd; }

- if (lockfd < 0 || dup2(lockfd, 99) != 99) + if (lockfd < 0 || dup2(lockfd, OPEN_MAX-1) != OPEN_MAX-1) { perror(lockfile); @@ -153,5 +158,5 @@ int lockfd;

close(lockfd); - lockfd=99; + lockfd=OPEN_MAX-1;

#ifdef FD_CLOEXEC