| 6 Dec 2025 |
 Mic92 | and yes it's the tarball cache in this case | 07:00:31 |
 Sergei Zimmerman (xokdvium) | Weird, I’m dogfooding that for some time and didn’t see any issues. Maybe the tarball cache gave out for unrelated reasons? | 07:03:26 |
| Sergei Zimmerman (xokdvium) | Did you happen to be running a somewhat recent-ish master with that? | 07:04:12 |
| Mic92 | I now did reset my .nix/cache | 07:04:14 |
| Mic92 | Let's see. | 07:04:17 |
| Sergei Zimmerman (xokdvium) | There was an issue with eelcos patch that started sharing the cache between threads | 07:04:33 |
| Mic92 | I am also testing this on other machines that will receive more load. This was on my macos machines. | 07:04:38 |
| Sergei Zimmerman (xokdvium) | That was reverted | 07:04:38 |
| Mic92 | Okay. I now rebased. I wasn't sure if this was included or not | 07:04:55 |
| Sergei Zimmerman (xokdvium) | In reply to @xokdvium:matrix.org
There was an issue with eelcos patch that started sharing the cache between threads I did test concurrently accessing that cache a bit and didn’t see issues btw. Let’s cross fingers, but that’s the primary suspect | 07:06:52 |
| Sergei Zimmerman (xokdvium) | https://github.com/NixOS/nix/pull/14620 | 07:07:18 |
| Mic92 | https://github.com/Mic92/nix-1/commit/7df48054782f3918a0ada9fcca194648712168f6 I also still got a remote builder hang. So I now added this patch as well for testing. | 07:07:26 |
| Sergei Zimmerman (xokdvium) | That’s the revert | 07:07:27 |
| Mic92 | * https://github.com/Mic92/nix-1/commit/7df48054782f3918a0ada9fcca194648712168f6 I also still got a remote builder hang. So I now added this patch as well for testing. Unrelated to your change. | 07:07:38 |
| Sergei Zimmerman (xokdvium) | In reply to @xokdvium:matrix.org
There was an issue with eelcos patch that started sharing the cache between threads * I did test concurrently accessing that cache quite a bit and didn’t see issues btw. Let’s cross fingers, but that’s the primary suspect | 07:10:20 |
| Mic92 | Sergei Zimmerman (xokdvium): so the issue I am facing is that our connection loop in nix-daemon --stdio has some check for interrupts, but for some reason also the SIGUSR1 from monitorfdhup is sent, it still doesn't exit that read. It's weird. | 07:10:23 |
| Mic92 | So know I took out the hammer and shutdown the unix socket. | 07:10:42 |
| Mic92 | * Sergei Zimmerman (xokdvium): so the issue I am facing is that our connection loop in nix-daemon --stdio has some check for interrupts, but for some reason also the SIGUSR1 from monitorfdhup is sent, it still doesn't exit that read loop. It's weird. | 07:10:58 |
| Mic92 | correction: ReceiveInterrupts sends SIGUSR1 | 07:11:44 |
| Mic92 | Not the nicest fix, but I can have the CI I am experiencing this with also not being blocked for too long, because it's some sort of production deployment. | 07:14:07 |
