00:11:01 ping? 00:11:27 pong 00:13:47 Okay, Had some odd IRC connection weirdness. All better now. 07:24:06 jperkin: Thank for the VBox settings 07:24:25 danmcd: Thank you for taking time answering the question 09:03:47 hi 11:52:54 i hope you can help me with this, i'm trying to create an overlay device using dladm but it return a varpd error, https://pastebin.com/RgxGywFF 11:53:00 am i doing anything wrong ? 14:56:01 @psarria anything interesting in varpd's log? ( e.g. "tail `svcs -L varpd`" ) 14:56:14 Your dladm for some reason couldn't door-call to varpd. Which is odd. 14:57:06 ret = door_call(client->vcl_doorfd, &darg); 14:58:38 that literally returned EBADF. I wonder if your dladm(8) invocation kicked off the varpd service (which it can do) but it wasn't fully up before it tried to speak to varpd? 14:58:43 Try the dladm again now that varpd is up? 14:59:00 (If you've a slower machine @psarria, that could explain it.) 15:12:36 btw. I just configured keepalived on two bhyve instances in triton (which I created via adminui with mac- and ip-address-spoofing capabilities) - then I reserved a public IP, which I used as the service ip in the keepalived config. and it just worked - failover works flawless 16:36:14 danmcd, thanks a lot for your time, it seems like the dladm create-overlay command generates varpd process core dump, https://pastebin.com/afRQ2S6q 16:36:30 danmcd, the machine is a empty smartos system doing nothing with 32GB ram and a xeon E3-1271 v3 @ 3.60GHz, it doesn't have any zones 16:42:12 danmcd, i want to think this test machine is enough for this 18:14:19 I'd like the coredump please. I'd also like the revision of the PI you're using. varpd dumping core is a reason you'd get EBADF and I'd like to see the core. 19:32:57 jperkin, I seem to be too pkgsrc-impaired to find the magic to get the link of unbound to ask for xnet before socket. When you get done quelling percona, I would appreciate a look at the sendmsg / xpg4 thoughts. 20:12:20 pjustice: what do you want to do? 20:14:27 Make unbound work. :) 20:15:05 (It's having -lsocket vs -lxnet sendmsg() issues that danmcd thinks are related to the decisions around xpg4_2, sockets, etc. 20:15:08 ) 20:15:22 Unbound 1.18 appears to use sendmsg & ancillary data w/o linking to libxnet or at least #define _XPG_2. 20:16:02 linking with `... -lsocket ... -lxnet ...` doesn' 20:16:04 This makes sendmsg() fail with EINVAL as modern ancillary data isn't supported by stock (SunOS 4, 4.3BSD) sockets. :upside-down: 20:16:05 t seem to fix it. 20:16:15 Oh you tried this? 20:16:31 Put -lxnet before or instead of -lsocket. 20:16:38 I tried forcing the extra library in, but I can't seem to get it to be in the LIBS list before -lsocket 20:16:53 because that was my understanding, must be before 20:18:18 Wait. 20:18:28 You actually DO need preprocessor magic. Try this: 20:18:45 -D_XOPEN_SOURCE=600 -D__EXTENSIONS__ 20:18:56 (In addition to -lxnet, regardless of order.) 20:19:22 Hmm, good point. But there's still the question of how to bludgeon pkgsrc into doing this. 20:20:57 There's no CFLAGS you can tweak in a makefile? 20:21:01 or CPPFLAGS ? 20:27:59 i think so, though jperkin probably knows the exact syntax for pkgsrc 20:28:16 there's probably illumos-specific examples lurking in there somewhere 20:28:39 like CPPFLAGS.xxxx += -D_XOPEN_SOURCE=600 -D__EXTENSIONS__ 20:28:54 just not sure if xxxx should be 'illumos' 'sunos' or something else 20:31:52 though having build problems because __EXTENSIONS__ isn't default reminded me to check 20:32:26 i was trying to build influxdb iox on illumos 20:32:52 and got stuck because croaring-rs won't build because of that 20:33:07 though I think all the fixes have finally filtered through 20:33:36 (they take a snapshot of the c source, include it in the rust repo, then build it with the rust wrappers) 21:09:16 Ok, with enough slimepatching, I got the pkgsrc build to include the CPPFLAGS. That plus -lxnet in the wrong order isn't enough. 21:11:34 pjustice: you can use BUILDLINK_TRANSFORM to change -lsocket into -lxnet -lsocket 21:13:11 try: BUILDLINK_TRANSFORM+= l:socket:xnet:socket 21:39:18 danke! 22:45:06 Ok, I didn't do anything elegant to get here, but with some hackery I got pkgsrc to do a build with the above defs and linking xnet before socket: 22:45:10 libtool: link: gcc -Wl,-rpath -Wl,/opt/local/lib -Wl,-rpath -Wl,/opt/local/lib -I. -I/home/pbulk/build/net/unbound/work/.buildlink/include -D_XOPEN_SOURCE=600 -D__EXTENSIONS__ -DSRCDIR=. -pipe -O2 -msave-args -fno-aggressive-loop-optimizations -std=c99 -D_REENTRANT -Wl,-rpath -Wl,/opt/local/gcc12/lib/gcc/x86_64-sun-solaris2.11/12.2.0 -Wl,-rpath -Wl,/opt/local/lib -o .libs/unbound-anchor 22:45:16 .libs/unbound-anchor.o ... 22:45:18 ... .libs/parseutil.o -L/opt/local/gcc12/lib/gcc/x86_64-sun-solaris2.11/12.2.0 -L/home/pbulk/build/net/unbound/work/.buildlink/lib ./.libs/libunbound.so /home/pbulk/build/net/unbound/work/.buildlink/lib/libexpat.so -lm -lssl -lxnet /home/pbulk/build/net/unbound/work/.buildlink/lib/libevent.so -lsendfile -lnsl -lresolv -lpthread -lrt -lsocket -lcrypto ... 22:45:23 ... /home/pbulk/build/net/unbound/work/.buildlink/lib/libnghttp2.so /home/pbulk/build/net/unbound/work/.buildlink/lib/libiconv.so -R/opt/local/lib -R/home/pbulk/build/net/unbound/work/.buildlink/lib 22:45:27 ... 22:45:30 No j 22:45:33 No joy. 22:46:20 the transform isn't visible in the normal build output 22:46:25 only in the work.log 22:48:41 I just hacked LIBS and CPPFLAGS in the Makefile.in. The compiles did include the defs, and the links did include the -lxnet before -lsocket (I just grabbed the last line for above, so it's not the daemon, but the commands for all the links are pretty much the same other than which .o files are linked, and the name of the output file.)