Close inherited file descriptors in forked child processes

ScriptController::StartProcess() forks a child to run unrar/7z or an
extension/post-processing script, but only ever closes the pipe fds
it created itself before calling execvp(). Any other file descriptor
the main process happens to have open at that exact moment is
inherited unchanged into the child (execvp does not close fds unless
they are marked close-on-exec).

In practice this means: if the main process has a file briefly open
for one queue item (e.g. mid-rename during Move) at the instant it
forks a child for a completely unrelated item (another unpack, or an
extension script), that unrelated child inherits the handle. The
original file then appears "busy" to the OS/filesystem for as long as
that unrelated child keeps running, and the Move fails with EBUSY
("Resource busy" on NFS mounts, surfaced as a "silly rename" .nfsXXXX
file).

Fix: compute the process's open-fd ceiling via sysconf(_SC_OPEN_MAX)
before fork() (sysconf is not async-signal-safe, so it can't be called
in the child), then in the child, after the stdin/stdout/stderr pipe
fds are wired up, close every other fd before execvp().

Author: wharris623

daemon/util/ScriptController.cpp

@@ -579,6 +579,15 @@ void ScriptController::StartProcess(int* pipein, int* pipeout)
 	}
 #endif
 
+	// Determine the highest fd we might need to close in the child, before
+	// forking - sysconf() is not guaranteed async-signal-safe, so it must
+	// not be called after fork() in the child branch below.
+	long openMax = sysconf(_SC_OPEN_MAX);
+	if (openMax < 0)
+	{
+		openMax = 1024;
+	}
+
 	debug("forking");
 	pid_t pid = fork();
 
@@ -619,6 +628,18 @@ void ScriptController::StartProcess(int* pipein, int* pipeout)
 			close(pout[1]);
 		}
 
+		// Close all other inherited file descriptors. Without this, any
+		// handle the parent process happens to have open at the moment of
+		// fork() - e.g. a file mid-rename during download post-processing -
+		// leaks into this child and keeps that unrelated file "busy" for as
+		// long as the child runs, causing spurious EBUSY / NFS "Resource
+		// busy" failures on the parent's operation. close() is
+		// async-signal-safe so this is safe to do here.
+		for (int fd = 3; fd < (int)openMax; fd++)
+		{
+			close(fd);
+		}
+
 #ifdef CHILD_WATCHDOG
 		write(1, "\n", 1);
 		fsync(1);