On 2017-08-23 02:41, Yuri wrote: Thanks for the quick reply, but... hmm. I'm gonna check this if and when I reproduce the situation, but my machine would seem to have bucketloads of space available: $ df -h Filesystem Size Used Avail Use% Mounted on /dev/root 15G 3.8G 11G 27% / devtmpfs 459M 0 459M 0% /dev tmpfs 463M 76K 463M 1% /dev/shm tmpfs 463M 6.3M 457M 2% /run tmpfs 5.0M 4.0K 5.0M 1% /run/lock tmpfs 463M 0 463M 0% /sys/fs/cgroup /dev/mmcblk0p1 63M 21M 43M 33% /boot tmpfs 93M 0 93M 0% /run/user/1000 Do you have any indication which filesystem/location JACK would be looking for the condition? Could it also be a case of flag misuse? M.

On 08/22/17 18:17, Yuri wrote: This patch should help: https://github.com/jackaudio/jack1/pull/74 Yuri

On 2017-08-23 03:54, Yuri wrote: Yuri, this is highly interesting. I can think of something that happened during testing which might correspond to what you found, although it still leaves some questions open. First a quick overview of my setup. My main process is a Java application. That application creates jackd instances via a fork (i.e., spawns a new process). It also creates jack_clients via native calls (using Neil C. Smith's jna-jack lib [1]) to connect to those newly created servers. Now, one of the problems I encountered today was that something went south when I tried to deactivate() those clients. Namely that I got a message on stderr that the JVM couldn't detach the native thread, upon which the entire JVM froze on me, with me having to SIGKILL it to get rid of it. Note that I also had manually to kill the jackd process, but that was achieved with a simple SIGTERM. This did indeed happened about 8 times (I have since circumvented the problem by calling close() instead of deactivate() on the client; not happy because I don't understand what the problem was, but at least it doesn't happen any more). There's still two problems however: - I can guarantee that none of my Java process nor any jackd instances were running what the problem happened -- or least none that showed up in ps. - I /think/ that I started the server successfully, after having had those had freezes, but before I had the "Too many servers active" error. Discarding the second problem for the time being, as I am not sure of it, the first one still remains. If, as you say, jack checks for dead PIDs, how can it not find free slots if no processes are running? Or does it perhaps not check the OS, but some internal register? In which case the freeze and kill would prevent that register from being cleared? This still doesn't make perfect sense, however, since, as mentioned above, I SIGTERM'd jackd, which can hardly count as a hard exit. The one thing that was broken was the jack_client in my JVM. So could that be it? Could it be that because of its freeze, even after having been killed, the JVM somehow retained resources associated with the client, and that *that* prevented jack from cleaning up its dead instances? Questions, questions. In case I get that issue again, would you mind telling in more detail what I need to do to get the information you mentioned, or really any pertinent information? Oh, and lastly and for reference, I'm running Jack 1.9.10. Regards, M. [1] <https://github.com/jaudiolibs/jnajack>