| 30 Jul 2021 |
 @timdeh:matrix.org | Which reminds me, one of our colleagues recently spruced up the old manix integrated fork of rnix-lsp if it's useful to anyone:
https://github.com/kreisys/rnix-lsp | 17:08:15 |
 yusdacra | In reply to @timdeh:matrix.org
I use that one quite a bit as well, don't think there is a better one except maybe manix? Using manix with skim / fzf is quite nice | 17:11:50 |
| @timdeh:matrix.org | yeah but it doesn't always seem to find everything I'm looking for unfortunately, but otherwise I agree completely | 17:35:02 |
 @kraftnix:matrix.org | speaking of debugging bud repl has been definitely increased my debugging speed | 18:48:57 |
| @kraftnix:matrix.org | on another topic, since we include earlyoom by default in the devos core profile. does anyone here you ZFS, i am using ZFS on root and constantly getting bitten by earlyoom not working with ZFS arc (see https://github.com/rfjakob/earlyoom/pull/191). does anyone have a workaround? my current workaround is migrating all my systems from zfs on root to btrfs on root... | 18:51:13 |
| @kraftnix:matrix.org | * on another topic, since we include earlyoom by default in the devos core profile. does anyone here use ZFS, i am using ZFS on root and constantly getting bitten by earlyoom not working with ZFS arc (see https://github.com/rfjakob/earlyoom/pull/191). does anyone have a workaround? my current workaround is migrating all my systems from zfs on root to btrfs on root... | 18:51:29 |
| @kraftnix:matrix.org | it's really sad watching my 128GB RAM workstation kill my qemu VMs because earlyoom doesn't interact with ZFS ARC :( | 18:56:25 |
 @d4hines:matrix.org | On the topic of escape hatches and onborading, do you think I could get a lot of the benefit of devos by basically using it as a way of interacting with home-manager on, say, an Arch linux installation? | 21:18:58 |
| @d4hines:matrix.org | That way I can always fall back to the native package manager and my teammates are never waiting on me to figure out Nix. | 21:19:47 |
| @kraftnix:matrix.org | i've been thinking about that as a way to introduce nixos to some friends tbh | 21:19:55 |
| @kraftnix:matrix.org | imagine pointing at a devos community profile and saying, install arch, install nix, run this and checkout this cool home-manager profile with my vim/tmux/fzf setup | 21:20:36 |
| @kraftnix:matrix.org | imho devos is such a nice experience to start nix, especially if you're not doing anything too complex / can work off other peoples profiles | 21:21:35 |
| @d4hines:matrix.org | I think I'll give this a shot. I'll be sad to lose out on the deep system-level declarations, but after talking with my tech lead about it, I'm just not strong enough in Nix/Linux/our toolchain to be certain I can always keep up. Using just the home-manager part might be a nice compromise. | 21:23:42 |
| @kraftnix:matrix.org | yeah, for shell related stuff it seems like a good way, but tbh i'm not sure how i would integrate my GDM/sway etc. setup into arch nicely, although maybe it won't be as hard as i'm thinking | 21:26:01 |
| @kraftnix:matrix.org | anyway on another topic, has anyone had issues with nix flake check when you have a lot of hosts? I've found the python vm test coredumping more as I've added more hosts (and will just pass if I rerun the twice with half the hosts each), systemd-coredump points to the pid of one of the python tests and contains systemd-coredump[134485]: Resource limits disable core dumping for process 123011 (python3). | 21:31:15 |
| @kraftnix:matrix.org | * anyway on another topic, has anyone had issues with nix flake check when you have a lot of hosts? I've found the python vm test coredumping more as I've added more hosts (and will just pass if I rerun them twice with half the hosts each), systemd-coredump points to the pid of one of the python tests and contains systemd-coredump[134485]: Resource limits disable core dumping for process 123011 (python3).
i'm guessing theres some resource limits, but i'm not sure where they might be of for what service (perhaps nix daemon)?
| 21:32:36 |
| @kraftnix:matrix.org | * anyway on another topic, has anyone had issues with nix flake check when you have a lot of hosts? I've found the python vm test coredumping more as I've added more hosts (and will just pass if I rerun them twice with half the hosts each), systemd-coredump points to the pid of one of the python tests and contains systemd-coredump[134485]: Resource limits disable core dumping for process 123011 (python3).
i'm guessing theres some resource limits, but i'm not sure where they might be or for what service (perhaps nix daemon)?
| 21:32:47 |
 @gtrunsec:matrix.org | 
Download image.png | 22:03:27 |
| @kraftnix:matrix.org | hmm, that's per vm-test though right? for me it's the digga profilesTest that is failing, i can run them in isolation or a couple at a time but not all of them (non-deterministically failing), i can actually run them all sometimes. | 22:05:56 |
| @kraftnix:matrix.org | In terms of overall system usage, I have many 10s of GB RAM free and no
noticeable strain on CPU or anything. I've been continuously running
tests (with minor changes to ensure all systems rebuild everytime + non-cached) and it's quite non-deterministic :(
I'm starting to think it could be the test-driver.py, I see it using exec() and join() which are red flags to me from some python multiprocessing i've done
| 22:15:03 |
| @gtrunsec:matrix.org | please, adding the virtual reosurce to here. https://github.com/divnix/digga/blob/main/src/tests.nix#L38 (and create the new branch for this test). then run it again | 22:18:40 |
| @kraftnix:matrix.org | yeah, I'll give it ago, currently I'm having issues reproducing the error, it's 1 in 4 times with all hosts at the moment | 22:19:42 |
| @kraftnix:matrix.org | which is a pain to test as it takes ~4mins to pass/fail each time. given that I literally just got it failing again I'll do the above | 22:20:27 |
| @kraftnix:matrix.org | running with memorySize = 4096; and cores = 4; | 22:23:03 |
| @kraftnix:matrix.org | * running with memorySize = 4096; and cores = 4;, let's see how it goes | 22:23:19 |
| @gtrunsec:matrix.org | Notice: memorySize = 4096; The volume depends on how many services you will be running. | 22:27:26 |
| @kraftnix:matrix.org | fails with 4096 as well, the accompanying python error (which I think I forgot to mention earlier is:
> Fatal Python error: _enter_buffered_busy: could not acquire lock for <_io.BufferedWriter name=''> at interpreter shutdown, possibly due to daemon threads
> Python runtime state: finalizing (tstate=0x434b00)
>
> Current thread 0x00007ffff77ec340 (most recent call first):
>
> /nix/store/bmxafbqrlvcwpcwd21irmirid4rkpank-stdenv-linux/setup: line 1286: 7 Aborted (core dumped) LOGFILE=/dev/null tests='exec(os.environ["testScript"])' /nix/store/va2yrwawaqbk676s0a0j9vcr8fj3bijf-nixos-test-driver-profiles/bin/nixos-test-driver
| 22:29:53 |
| @gtrunsec:matrix.org | https://stackoverflow.com/questions/45267439/fatal-python-error-and-bufferedwriter | 22:34:59 |
| @kraftnix:matrix.org | this looks like the reason why i always use ThreadPoolExecutor with python multi-processing as it cleans itself a lot better, i'm now testing with a test-driver that does an os.exit(0) at the of the script as suggested by the post you linked, i was about to rewrite the test to use an ThreadPoolExecutor anyway | 22:42:17 |
