I am running in this error while running my program (though never opening /dev/null)
couldn't open "/dev/null": Too many open files
I assume that I am leaking filehandlers at some point. But as I am not using raw open or close but with-open-file and sb-ex:process-close any process I create with sb-ext:run-prgram I am confused. As I do not know where I am leaking it would be pointless to post any code as it is too much to copy-paste and random samples wont help either.
Therefore, how can I track filehandlers and isolate leaks?
This could be separate from your Lisp program, and rather a background issue on your system. Because you mention /dev/null, it sounds like you're on some flavor of Unix, and something like lsof might help in tracking down what's still open. The error messages aren't SBCL specific, so typical searched will only help you find general answers, though some of the investigation techniques may be relevant. Since you haven't posted any SBCL code, it's hard to provide any SBCL specific responses. (But maybe there are SBCL specific profiling tools. There could also be a disconnect between your calls letting file descriptors get closed, and SBCL actually closing them.
Now, even though it sounds like you're using the Common Lisp APIs correctly, there could be some surprising edge cases. Are you sure you're not holding references to them anywhere that would keep them from getting released? A global list somewhere, or, doing things in the REPL where *, **, and *** variables hold past results, could all contribute.
Now, another option is that the implementation might still have file descriptors open, even if the Common Lisp stream is closed. with-open-file binds a stream for you, and that's an implementation's wrapper around the file descriptor. (I'd be surprised if SBCL is leaking like that, though.) For instance, if the output hasn't been flushed, it might be that the file descriptor stays around for a while. Using force-output or clear-output might help with some of those issues.