02:08:53 <heston76> Alrighty, everything is now update to 15.1-STABLE
02:10:28 <elivoncoder> nice
02:10:47 <elivoncoder> im still rc3 going to reinstall later just because
02:11:01 <elivoncoder> well not rc
03:25:35 <skered> Well that wasn't dramatic.  pkgbasify was quick and just worked.
05:38:39 <rtprio> yep
05:58:38 <hc> rtprio: Welcome to the world of scientific research. I've been using nixos since 2016 on various systems, including nixos unstable on my work laptop. Though I'm conservative when it comes to running production servers and still prefer a more proven system there
05:58:57 <hc> There's a lot of interest in systems like nix in the functional programming research community, too
06:14:00 <Aedil> I did it. My VM is on 15.1-RELEASE.
06:47:22 <MelanieUrsidino> scientific research‽
07:42:00 <hc> MelanieUrsidino: https://edolstra.github.io/pubs/phd-thesis.pdf
07:43:29 <MelanieUrsidino> o_O
10:36:17 <Macer> i've never seen a p0 release
10:36:42 <Macer> is that from the bug that was sent out in the mailing list a couple days ago?
11:26:10 <voy4g3r2> hc: have you looked at the software bill of material (SBOM)? The concept of being able to "track" software and its dependencies have always been a "fun" avenue as inconsistencies are that constant variable to balance.. back to reading it a little more
12:35:43 <hc> voy4g3r2: Haven't looked into it beyond briefly trying out syft, but it seems to have limited support for .cabal files
12:36:30 <hc> I like the idea of sbom. It is an attempt to make an important aspect of software security (transitive dependency versions) more visible
13:22:57 <td123> just upgraded a vm from 15.0 to 15.1 using freebsd-update and it went smoothly, thanks for making this process so easy
13:44:54 <DarkUranium> Q. I'm debugging something, and I need to be sure --- does `fetch` do keep-alive / reuse connection if I call it multiple times on the same site in a short timespan?
13:45:02 <DarkUranium> Or is each run of `fetch` a new connection, always?
13:49:30 <hc> You mean the command fetch as in /usr/bin/fetch? The shell should fork,exec on each invocation, how can it preserve state and reuse a connection?
13:55:24 <DarkUranium> hc: Correct. And you never know, there could (in principle) be a `fetchd` to preserve it over short timespans, or the process forks a background process that stays around for a minute or so with some per-site socket.
13:55:37 <DarkUranium> Just doing a sanity check because I'm dealing with a heisenbug of networking ......
13:56:17 <DarkUranium> (TL;DR most fetches work, occasionally I get a "connection reset by peer" ...... to an internal [to bhyve/VM] network)
13:56:34 <DarkUranium> (my reverse proxy is even weirder, it's pretty consistently every 2nd request that fails)
14:01:05 <hc> DarkUranium: true. I don't know fetch enough to be able to say with certainty, though I'd be really surprised
14:03:12 <DarkUranium> Same, but at this point, I felt like I needed the sanity check.
14:03:18 <DarkUranium> The issue's driving me crazy >_<
14:04:22 <hc> Yeah, I know you need a sanity check; you need absolute certainty and I can't help you with that
14:04:35 <DarkUranium> Fair, thanks anyway ^^
14:05:18 <DarkUranium> Okay, this is weeeeeeeeeird.
14:05:42 <DarkUranium> The jail has a 3.8-12% packet loss (too small sample size to tell for sure) to a *container in VM on the same machine*.
14:05:50 <DarkUranium> The host (of the jail) has 0.0%.
14:07:44 <scoobybejesus> Maybe too early to start asking this, but intel or Realtek nic?
14:09:35 <DarkUranium> scoobybejesus: It doesn't go via the NIC, it's jail -> host -> bhyve VM -> container
14:09:50 <DarkUranium> But I can check if it matters.
14:10:24 <hc> DarkUranium: Have you run fetch with -v yet? It should give you some clues as to whether it uses connection keep alice
14:11:09 <hc> I just ran it with two URLs and it looks like even when specifying two URLs in one go to the same host it will establish two connections in sequence
14:11:38 <hc> (-vv might be more helpful even)
14:13:44 <DarkUranium> Apparently, I was being DoS'd yesterday. But that was yesterday.
14:25:45 <DarkUranium> Okay, I *think* I managed to get a bit further.
14:25:55 <DarkUranium> `ping` form the jail has a packet loss. `ping` from host does not.
14:26:04 <DarkUranium> (seems to be kinda random, 0-12%)
14:26:36 <DarkUranium> traceroute is different, from the jail, it goes via 10.88.0.1, a bridge
14:28:15 <sig`> DarkUranium: and your virtual network path issue?
14:28:39 <DarkUranium> sig`: Hm? Er, which path issue?
14:30:41 <sig`> DarkUranium: your host will be good because the jail has loss because only the jail path crosses epair and bridge
14:31:00 <sig`> vnet jails use their own isolated net stack and epair/bridge
14:31:06 <sig`> just learned this too
14:32:07 <DarkUranium> Sure, but I'd expect 0% loss since it's not an *actual* cable. But maybe.
14:32:29 <DarkUranium> Either way, the packet loss is no longer showing up *at all*, *ever* (as of a re-test a minute ago) ...... but nginx is still getting reset connections.
14:32:48 <DarkUranium> hc: FWIW, not only does it *not* use Keep-Alive, it actually sends `Connection: close` explicitly.
14:32:52 <DarkUranium> So it's safe to say there's no reuse, at least.
14:33:30 <sig`> hmm, tcp connections being reset?
14:33:47 <DarkUranium> Yeah, to summarize (to put it all in 1 place again):
14:34:16 <DarkUranium> My setup is `jail (nginx reverse proxy) -> bhyve VM -> Linux -> container`, in terms of what connects to what.
14:34:37 <DarkUranium> All but 1 container have this problem. 1 works, in the same Linux system. No idea why.
14:34:47 <DarkUranium> (out of 5 or so)
14:35:30 <DarkUranium> Every 2nd request (or so, so far it seems like it's *actually* every 2nd request, but that's hard to confirm), nginx gets me a "502 Bad Gateway" in the browser, and logs it as: kevent() reported about an closed connection (54: Connection reset by peer) while reading response header from upstream,
14:36:03 <DarkUranium> Upstream IP is correct in the log, so it's not some weird round-robining going on in nginx.
14:37:37 <sig`> probably not nginx....
14:37:58 <sig`> nginx shows the coorect upstream ip?
14:38:33 <DarkUranium> Exactly. I'm thinking either keepalive (between nginx/proxy & backend, not user & proxy) or a firewall misconfiguration or an IP conflict.
14:38:57 <sig`> any old upstream connections?
14:39:12 <DarkUranium> No, because I also tried restarting nginx and such.
14:39:14 <sig`> https://freebsdfoundation.org/wp-content/uploads/2020/03/Jail-vnet-by-Examples.pdf?utm_source=chatgpt.com
14:39:32 <DarkUranium> In fact, *reloading* (not even restarting) nginx's config on the proxy seems to pretty reliably make the next request fail.
14:39:35 <sig`> DarkUranium: ok
14:39:53 <DarkUranium> (but not 100% reliably, nothing's 100% here, sadly ... which is why I'm struggling with diagnosing it)
14:39:56 <sig`> you have 1 jail working well out of the 5?
14:40:05 <DarkUranium> 1 Linux (podman) container, but yes.
14:40:26 <DarkUranium> The only difference, AFAICT, is that the one that works well uses a non-wildcard certificate. But I don't see how that could *possibly* affect the connection in this way.
14:40:37 <sig`> compare the working one app runtime with the broke ones?
14:41:09 <nimaje> hm, can you share more of your networking setup (ifconfig and routing tables)?
14:41:12 <sig`> have you tried disabling upstream keepalive to see if that fixes it
14:43:45 <DarkUranium> Good point, I've not done it at upstream yet.
14:45:01 <DarkUranium> ... so, disabling keepalive makes it not work at all. Which makes sense as to why reloading would break things (presumably, it drops keepalive connections due to [potential] config changes)
14:46:50 <sig`> ah yeah
14:48:22 <DarkUranium> Every 2nd request is how 504 Gateway Time-out. So it goes 502 -> 504 -> 502 -> 504, instead of 502 -> ok -> 502 -> ok
15:22:29 <mosaid> HI
15:23:08 <voy4g3r2> DarkUranium: a few thoughts 1.) is your network topology setup 2.) what type of firewall setup? 3.) what network card
15:24:05 <voy4g3r2> for example.. host firewall and then have a firewall that is on the individual vnet jails itself.. unwinding what you can on the network and what is the number of interfaces and bridges that you are using..
15:25:08 <DarkUranium> voy4g3r2: It's an Intel i210, but note that none of the traffic passes through it.
15:25:38 <DarkUranium> None that's relevant to the problem at hand, anyway. The issue is between the reverse proxy and the contain behind it.
15:26:10 <mosaid> I want to ask a question.. could I  but every part of my system in separate partition like usr, var, tmp.. and get a fresh 14 version on usb
15:26:20 <mosaid> then upgrade through it
15:26:38 <DarkUranium> s/contain/container/
15:26:41 <mosaid> or will go into problem for?
15:26:51 <DarkUranium> voy4g3r2: it's pf on FreeBSD end, iptables on Linux/VM.
15:26:58 <DarkUranium> Podman in Linux as well.
15:40:29 <DarkUranium> So, turns out it *does* reach the backend after all. It was misconfigured and hiding error_log.
15:40:30 <DarkUranium> >  [info] 345#345: *783 epoll_wait() reported that client prematurely closed connection, so upstream connection is closed too (104: Connection reset by peer) while connecting to upstream
15:40:36 <DarkUranium> (this is backend's own frontend)
15:40:53 <DarkUranium> In other words: proxy thinks the backend closed the connection prematurely, and the backend thinks the proxy did it.
19:11:40 <ridcully> does anyone know how to completely remove a previously `fetch`ed release with AppJail?  i used `appjail fetch destroy -v $v default` and it's not longer in the list, but there are still three datasets mounted with $v in the name
19:30:42 <rwp> Is the tool expecting you to destroy the datasets manually?
19:42:52 <ridcully> it removes other dataset(s) correlating to $v.  so my options are to just remove the other residue myself, create a ticket/minimal example or investigate the source.  my hope was, that i am not the only one using AppJail around here