r18583: a nasty hack to allow me to monitor the number of open file

descriptors in smbd on all build farm machines. I suspect we have a fd
leak somewhere, but its hard to track down.

I know part of the problem is the number of (fake) network interfaces
we define in the build farm tests, with each of them listening on a
whole bunch of different protocol ports. That chews up around 48 file
descriptors just to startup. I don't think thats the real problem
though, and I suspect something else is leaking file descriptors on
some hosts.
(This used to be commit 83bf458ec98d9f2a21b3748802f41abcbcc1e0b2)

1 files changed, 13 insertions, 0 deletions

diff --git a/source4/smb_server/smb/receive.c b/source4/smb_server/smb/receive.c
index fd80224787..f352db7488 100644
--- a/source4/smb_server/smb/receive.c
+++ b/source4/smb_server/smb/receive.c
@@ -26,6 +26,7 @@
 #include "smb_server/smb_server.h"
 #include "smb_server/service_smb_proto.h"
 #include "ntvfs/ntvfs.h"
+#include "system/filesys.h"
 
 
 /*
@@ -77,6 +78,18 @@ NTSTATUS smbsrv_recv_smb_request(void *private, DATA_BLOB blob)
 
 	smb_conn->statistics.last_request_time = cur_time;
 
+	/* a temporary hack to allow me to find a possible file descriptor leak in 
+	   build farm machines (tridge) */
+	{
+		static int maxfd;
+		int xfd = open("/dev/null", O_RDONLY);
+		close(xfd);
+		if (xfd > maxfd) {
+			maxfd = xfd;
+			DEBUG(0,("MAXFD=%d\n", maxfd));
+		}
+	}
+
 	/* see if its a special NBT packet */
 	if (CVAL(blob.data, 0) != 0) {
 		req = smbsrv_init_request(smb_conn);