Smithx10: I have a few questions! ;)

it builds fine for us and is available in the trunk package repo, is there any particular option or change to the build that you need that we could integrate rather than you having to build your own?

are you using the pkgbuild image and 'run-sandbox' to configure the environment first?

jperkin: nope.... I just cloned it into a zone. Where are those instructions again for the pkgbuild image? I just pulled the latest version*

jperkin: I just noticed in the bind logs kb.isc.org/docs/aa-00508

Smithx10: the tl;dr is to provision the latest pkgbuild, 'run-sandbox trunk-x86_64', cd /data/pkgsrc, git pull (probably --force as the image is a bit behind at this point), then build as usual - docs at github.com/TritonDataCenter/pkgsrc/wiki/pkgdev:setup

Smithx10: it looks like there's a 'tuning' option that passes '--with-tuning=large' and increases (amongst other things) maxevents to 1024, so I'll just enable that option for the next build

bahama-: do we run bind in any tiny zones which kb.isc.org/docs/aa-01314 might negatively affect?

can avoid the RCVBUFSIZE and RESOLVER_NTASKS changes if necessary

thanks jperkin

maybe I'll wait than.... im not dropping requests that I know of , so it might just be an annoying message

jperkin: I don't think *we* do, but Joyent might.

But I think in general, tuning=large is probably a better option for the build.

I think that in the case of "smaller and low-end BIND servers", performance isn't going to be such an issue.

The minimum zone size is about 128MB (not a hard limit, but the os in general gets cramped below that), which would be way more than a small bind server needs.

Any avid SMF users around that could teach me how to make caddy reload it's config with a refresh method?

This is what I have so far and it works, but when doing svcadm refresh caddy it tries to start a new caddy process somehow

And it doesn't seem to clean up the old one, so it complains:

Error: loading initial config: loading new config: starting caddy administration endpoint: listen tcp 127.0.0.1:2019: bind: address already in use

could that be a bug in your caddy config file?

because the commands look right to me.

it seems like it's having trouble finding the admin endpoint.

> Because this command uses the API, the admin endpoint must not be disabled.

though it does look like your new config has the admin endpoint defined...

nahamu (LIBERA-IRC): thanks for taking a look

These are the caddy logs for more context

When checking running processes after trying the refresh method I can see two caddy processes, so it's seems that SMF / caddy has trouble cleaning up / reloading the config

oh!

It seems like the original caddy process might be having trouble re-binding to that same adming address.

*admin

I bet the error message is coming from the running server process, not the reload process.

You could test my theory by running the reload command manually and seeing that the logs still show the error message as opposed to that error showing up in the shell where you run the reload.

which means it's an issue with how caddy is trying to perform the reload. It might be making some sort of Linux-y assumption about being able to share the port binding.

something like SO_REUSEPORT

which it does look like illumos defines.

SO_REUSEPORT had to be patched out as it's hidden behind _KERNEL

so it's probably that

Ah, someone who knows what they are talking about! ;)

Instead of me just stabbing in the dark...

Thank you the insights jperkin (LIBERA-IRC) and nahamu (LIBERA-IRC)

So for the moment, caddy reload like it's implemented doesn't work on illumos and only a restart would work, correct?

illumos.org/issues/12455 looks stuck

That would be my guess. :(

Would have to find the relevant golang code to confirm the culprit.

github.com/caddyserver/caddy/blob/master/listen_unix.go#L104-L105 looks pretty guilty. I'm surprised you don't get a log message about it.

haha, there it is.

Hello folks. We in illumos are getting close to switching default compilers. One of the switching components is moving from gcc10.3 (which we build with DEBUG on every SmartOS release since early 2022) to gcc10.4.

This pi:

MD5 == 70c2c165c9e4b66b649335423ba24f41

Was built with gcc10.4, non-DEBUG. I've been testing a slightly older (some small upstream merges missing) version and it passed the tests same as stock, same slightly older version.

This one is going on my Kebecloud CNs and the piadm(8)-testing long-lived SmartOS VMware VM on my workstation.

I can burn an ISO or USB image for those so inclined. piadm(8) users can use the .tgz PI, as there's no impactful loader changes between that and last release.

nahamu (LIBERA-IRC): jperkin (LIBERA-IRC) sent a kind mail to Hokuto asking if I could be of help

@danmcd gist.github.com/Smithx10/9694a1369e7b26d425aa8263b7baa2d3 hung dladm add-aggr

ahh

can you do 'findstack -v' instead?

(mostly want to see the args to ddi_dma_mem_alloc())

i'm working on a fix for this that should hopefully make it's way upstream

just multiple fires have prevented me from finish the work to test it

@jbk you run into this at your current job?

yes

yeah -- basically the driver's trying to allocate a bunch of 9216 bytes of DMA memory.. which unlike regular kernel or application memory which has the benefit of using the MMU on the CPU

this needs to be physically contiguous.. which on a system running for a while can take some time

my proposed fix is to just do chunks of 2k since the card can split an incoming packet across multiple buffers (and 2k would still be able to handle a 9216 packet w/o hitting NIC limits on # of segments)

just the driver needs to be able to handle it

i dont think this system ever finds that lol

because it never gets added

it can take quite a while..

i'm guessing if there's VMs on the system, it probably makes it even worse since all of the VM memory is effectively off limits (IIRC)

so the system has to effectively 'defrag' the memory that's left

I suppose if our IOMMU support was better, that might avoid this as well (though I have no idea what the scope of that work would entail)

bahamat: where is a good place to see the documentation about creating triton rbac v2 cross account manta roles / policies

github.com/TritonDataCenter/sdc-clo…index.md#rbac-users-roles--policies ?

Smithx10: Yeah, that's it. You just do type=account instead of subuser.

yea

And you can leave out the ID, triton will figure that out for you.

triton rbac apply kinda forced me to figure out the objects, glad it was in cloudapi