00:00:18 <parv> Ed M on pf: https://hachyderm.io/@emaste⊙ms/111132944611315615 ; https://hachyderm.io/@emaste⊙ms/111133934066815915 ; https://hachyderm.io/@emaste⊙ms/111138399698480459
00:00:20 <VimDiesel> Title: Ed Maste: "The FUD about #FreeBSD's pf port is rather tediou…" - Mastodon
00:05:59 <_xor> That 3rd link is awesome.
00:53:41 <TommyC> _xor: Is the syntax the same? If they are, we could use the same lexer and parser even if the backend is handled differently.
01:34:19 <rtprio> TommyC: i think there's more than just the lexer/parser
02:34:10 <_xor> Hmm, is there a signal that triggers the process to exit with a success code?
02:45:43 <_xor> Front-end would probably be the least of the worries, I would think.
02:47:00 <_xor> I imagine it would be the implementation-specifics of the processing/matching engine, with my comment earlier basically alluding to that thread-safe in FreeBSD and can be scheduled on multiple cores or whatnot.
02:48:53 <_xor> I did read a comment saying that packet processing doesn't benefit as much from multi-threading since the nature of processing/matching typically involves a window of just a few packets before all operations would be blocked (e.g. re-assembling fragments might be one example).
03:52:40 <rwp> _xor, Most signals are due to an exceptional condition and therefore the process should exit with a non-zero exit code.
03:52:43 <rwp> man 3 signal
03:52:55 <rwp> Then look at the action and description of the action.
03:53:24 <rwp> However a program can be written to do other things. And actually incorrectly handling signals is a too common bug in many programs.
03:54:03 <rwp> Why do you want to kill a program and have it exit zero?
03:54:15 * rwp is now relocating from here to there
07:22:40 <moviuro> Packaging mishap in acme.sh? Extracting acme.sh-3.0.6_1: 100% ## [: !-f: unexpected operator
07:24:06 <parv> Interesting
07:25:32 <parv> Would that be in some post-install script?
07:27:56 <moviuro> yes parv , looks like it. happened on two different jails
07:29:36 <parv> moviuro, Do you have the file name?
07:29:42 <moviuro> nope
07:39:41 <meena> https://github.com/freebsd/freebsd-ports/blob/main/security/acme.sh/pkg-install
07:39:42 <VimDiesel> Title: freebsd-ports/security/acme.sh/pkg-install at main · freebsd/freebsd-ports · GitHub
07:41:17 <meena> Line 6:              if [ !-f /var/log/acme.sh.log ]
07:41:17 <meena>                       ^-- SC1035 (error): You are missing a required space here.
07:41:52 <meena> moviuro: wanna submit a bug / patch?
07:42:16 <moviuro> meena: should I do that on freebsd bugs or on github?
07:42:22 <moviuro> (and yes, I can do that)
07:43:22 <meena> Also, I'm not sure that script is pkg -c / pkg -r safe
07:47:00 <meena> imagine if https://man.freebsd.org/pkg-lua-script(5)   had examples of how to convert bad shell scripts to good lua scripts
07:47:01 <VimDiesel> Title: pkg-lua-script(5)
07:47:05 <parv> meena, I was searching for a file in "acme.sh*.pkg" but could not find one. Oh, that is stuffed right in +MANIFEST
07:50:04 <moviuro> meena: if you want to voice your concerns: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=274348
07:50:07 <VimDiesel> Title: 274348 – security/acme.sh pkg-install bug in 3.0.6_1
07:52:35 <meena> moviuro: thanks
08:00:05 <moviuro> meena: doesn't pkg(8) pass some env variables like $DEST_ROOT or similar?
08:23:07 <meena> I don't know
08:23:50 <meena> i'd have to read the code, or create a package that puts env output into a log file
08:30:07 <meena> PKG_ROOTDIR
08:33:50 <meena> ${PKG_ROOTDIR}${PKG_PREFIX}
08:37:01 <meena> instead of of /usr/local. and i think /usr/bin/install can stay the way it is, since it's not a binary that needs to be of a certain ABI for this operation to succeed
10:58:35 <cdrmack> o/
10:58:38 <cdrmack> RhodiumToad, you there?
10:59:02 <RhodiumToad> ?
10:59:13 * RhodiumToad appears as if summoned
10:59:20 <cdrmack> damn, that was quick
10:59:32 <cdrmack> do you have few minutes to speak a bit more about make and makefiles?
10:59:41 <RhodiumToad> sure
10:59:45 <cdrmack> awesome
11:00:13 <cdrmack> So I have read yet few more articles and man page once again.
11:01:18 <cdrmack> First question - makefiles in usr/share/mk are generic makefiles that we can/should include in our own projects or maybe these should be used only when building FreeBSD from the source?
11:02:00 <RhodiumToad> bsd make includes /usr/share/mk/sys.mk automatically (iirc) and obviously therefore anything it includes.
11:02:07 <cdrmack> I still didn't figure out how to force make to move my *.o files to `build` directory, that's how I have found bsd.obj.mk
11:02:28 <RhodiumToad> but the rest is really best left alone unless you're building freebsd itself
11:03:50 <RhodiumToad> when it comes to having a separate build dir, that's getting into territory where bsd make differs from other makes, and so you need to start thinking about portability.
11:04:42 <cdrmack> hmmm
11:04:50 <cdrmack> okay, one step at a time
11:05:08 <cdrmack> I went through the bsd.obj.mk file and found comments how we can set custom build directory
11:05:19 <RhodiumToad> personally, I use exclusively GNU make unless I'm working on freebsd (src or ports)
11:05:33 <cdrmack> if I create `obj` in my source tree it will be used automatically
11:05:53 <cdrmack> but there should be a way to set custom one with env MAKEOBJDIR=<stuff> but it doesn't work for me
11:06:14 <cdrmack> maybe I should switch to GNU make, there is no really a good reason why I'm forcing myself to use it
11:06:53 <cdrmack> except the fact that it's here by default and I'm trying to learn/focus on what's available out of the box
11:07:30 <cdrmack> I can stick with `obj` directory for now, not a big deal though - was just curious why it doesn't work
11:07:39 <cdrmack> since my main motivation is to keep learning things
11:07:57 <RhodiumToad> eh. you can't build more than like 3 ports before something pulls in gmake as a build dep
11:09:20 <cdrmack> I see, good to know
11:09:47 <cdrmack> there are bunch of materials about gnu make, saw that wildcards feature which makes such things pretty simple
11:09:48 <RhodiumToad> maybe I exaggerate slightly but gmake is very commonly used by ports
11:10:28 <RhodiumToad> one thing that gmake isn't very good at is numeric comparison, that's about the only feature bmake has that gmake doesn't
11:11:06 <RhodiumToad> however, bmake's syntax for most complex stuff looks like linenoise, whereas gmake has actual names for functions
11:13:24 <cdrmack> I see, will stick with learning bmake basics and then move to gnu make then
11:13:29 <cdrmack> do you mind asking few more questions?
11:13:44 <RhodiumToad> go ahead
11:14:30 <cdrmack> last time you mentioned keeping separate files for list of source files only in the subdirectories, do you have an example of that somewhere so I can see?
11:16:19 <RhodiumToad> er
11:17:12 <RhodiumToad> probably not, unfortunately
11:18:00 <cdrmack> let's say I have `src` directory with `foo.c` and `bar.c`
11:18:04 <cdrmack> inside
11:18:46 <cdrmack> should I create there `Makefile` with sth like `SRC:= foo.c bar.c` and then .include that in my main Makefile?
11:19:01 <RhodiumToad> I wouldn't call it Makefile in such a case
11:19:09 <cdrmack> okay, so it can be any file
11:19:42 <RhodiumToad> since Makefile is the default name used by make, its presence in a directory suggests you can run make in that directory to do something useful
11:19:43 <cdrmack> .include "file" will simply attach content of that file in place of the .include line? like #include in C?
11:19:48 <RhodiumToad> yes
11:20:32 <cdrmack> does the order matter? do I need to .include "src/notaMakefile" before I will use that variable inside?
11:20:59 <cdrmack> not sure if make parses Makefile once or more
11:21:23 <RhodiumToad> the order sometimes matters and sometimes doesn't. Remember that when you assign a variable with = rather than := (and you should almost always use = unless you know why not to), the value isn't expanded until referenced
11:21:37 <RhodiumToad> the makefile is parsed once
11:21:47 <cdrmack> lemme try in the background, one sec
11:28:19 <cdrmack> looks like it doesn't matter where I include this file
11:32:57 <cdrmack> now I have another problem though
11:36:03 <cdrmack> after including that file in my Makefile, my ${SRCS} variable (defined in a separate file in a subdir) stores "foo.c bar.c" but should have "src/foo.c src/bar.c"
11:36:27 <cdrmack> I have used some fancy replacement to define objs based on srcs, OBJS= ${SRCS:%.c=%.o}
11:36:29 <RhodiumToad> are you planning to extend this to multiple subdirs?
11:36:51 <cdrmack> probably sth similar can be done with adding dir in front but I have no idea what kind of syntax that is to even start searching for some docs
11:37:15 <cdrmack> at this stage I planned to have only "src", "inc" and "tests"
11:37:24 <RhodiumToad> stuff like adding the dir in front is another thing that varies between different makes
11:38:35 <cdrmack> ;_;
11:39:01 <cdrmack> looks like I will have to read about GNU Make sooner than I initially planned
11:39:13 <cdrmack> two last questions and I need to go with a dog, sorry
11:39:43 <cdrmack> 1. do you have different makefiles for building binary and library or maybe you keep everything in one Makefile and simply add new targets?
11:40:17 <cdrmack> 2. what kind of syntax this is "OBJS= ${SRCS:%.c=%.o}"? where I can read more about it to solve other issues when I need it?
11:40:42 <RhodiumToad> I think $(SRCS:%=src/%)  might work in both bmake and gmake but I've not tested it recently
11:41:32 <RhodiumToad> for bmake see "Variable modifiers" in the manpage, for gmake see "Substitution references" in the info or html doc
11:42:27 <RhodiumToad> bmake has a huge array of variable modifiers that can make variable refs look like linenoise, whereas gmake relies on named functions instead
11:42:51 <RhodiumToad> e.g.  $(SRCS:M*.c)  in bmake  vs.  $(filter %.c,$(SRCS))  in gmake
11:44:04 <RhodiumToad> note that while both ${foo} and $(foo) work in both bmake and gmake, outside of the BSD world the $(foo) form is universally used
11:49:15 <cdrmack> I see
11:49:18 <cdrmack> thanks a lot once again
11:49:34 <cdrmack> will spend some time on these resources before bothering you again :)
11:49:45 <cdrmack> have a good one, gotta go with the doggo
11:49:46 <cdrmack> o/
12:04:07 <meena> RhodiumToad: how hard would it be to add those GNU functions to bmake?
12:05:10 <RhodiumToad> dunno
12:09:43 <RhodiumToad> currently in bmake, $(foo bar) is a legitimate reference to a variable named "foo bar"
12:10:04 <RhodiumToad> so adding gmake-style functions would break that
12:25:11 <meena> how do you declare such a variable?
12:25:28 <RhodiumToad> indirectly
12:26:10 <RhodiumToad> foo = bar baz   $(foo) = quux
12:26:46 <RhodiumToad> "... This allows almost arbitrary variable names, however names containing dollar, braces, parenthesis, or whitespace are really best avoided!"  -- so sayeth the manpage
13:21:43 <cdrmack> is there any way to print all default variables that make uses behind the scenes? there are simply too many options in the debug mode (-d) :P
13:21:59 <cdrmack> GNU make has these in man but I see none for bmake
13:23:29 <cdrmack> (going through -d A right now)
15:49:42 <_xor> rwp: I was pretty sure exiting 0 on a signal wasn't something that was expecting to happen, but I just wanted to make sure.
15:50:08 <_xor> Also, true and false being inverted in shell scripts is...annoying sometimes.
15:52:35 <meena> shell scripting is unnecessarily hard
15:52:44 <fancycade> I made a mostly working port of ee in zig: https://git.sr.ht/~fancycade/eez
15:52:45 <VimDiesel> Title: ~fancycade/eez - Zig port of ee - sourcehut git
15:59:37 <meena> fancycade: cool
16:12:17 <LxGHTNxNG> if I'm just bending strings I prefer Tcl
16:18:14 <polyex> i did a make installworld installkernel and i can't rm the DESTDIR, even with sudo
16:18:31 <polyex> i get operation not permitted errors
16:20:10 <isley> some of the files will have flags set. probably schg, maybe some others. you can see this with ls -lo
16:20:35 <isley> chflags noschg on the files should fix that up for you
16:24:23 <polyex> ls -lo in lib/ says schg on them
16:24:54 <RhodiumToad> schg is set on the most critical files, like libc and rtld
16:26:16 <polyex> s in schg mean secure or system?
16:26:29 <RhodiumToad> system
16:26:38 <RhodiumToad> there's a uchg flag which is the user equivalent
16:27:09 <polyex> wow cool
16:27:15 <RhodiumToad> the owner of a file can set/clear uchg, but only superuser can set schg, and not even the superuser can clear schg if the securelevel has been raised
16:28:23 <polyex> is it good practice to always wipe the build dir before the build step?
16:29:02 <RhodiumToad> for building the source tree? no, not usually
16:34:10 <polyex> no sorry not build dir, the destdir of installworld installkernel
16:35:21 <polyex> isley ty that worked. it's kinda tedious going into each dir with schg flag files and setting noschg on each. to do it recursively i type sudo chflags noschg -R dir?
16:40:36 <RhodiumToad> oh, the destdir of installworld/kernel should usually be cleaned out first, yes
16:41:04 <RhodiumToad> chflags -R noschg dir
16:44:26 <polyex> that worked great, tyvm
17:00:38 <_xor> meena: Yes, it is.
17:01:07 <_xor> meena: I've been using https://github.com/go-task/task for a good while now and it's definitely been a net positive
17:01:08 <VimDiesel> Title: GitHub - go-task/task: A task runner / simpler Make alternative written in Go
17:01:46 <_xor> There's also just, which I used for a bit, and it's good too, but I preferred yaml (yeah, yeah, I know) over make file syntax.
17:04:50 <meena> _xor: yaml is not an adequate language
17:07:27 <meena> never mind, someone did https://metacpan.org/pod/YAMLScript
17:07:28 <VimDiesel> Title: YAMLScript - metacpan.org
17:08:35 <polyex> RhodiumToad how do you script a freebsd installworld installkernel? i have to chflags -R the DESTDIR then rm -rf it before clean the env but that has to be run as sudo. so do you put sudo ... lines into the script, or leave them out and remember to run the whole script with sudo like sudo myscript?
17:09:32 <meena> https://ruudvanasseldonk.com/2023/01/11/the-yaml-document-from-hell there's probably worse things, but this is a nice summary
17:09:34 <VimDiesel> Title: The yaml document from hell
17:12:30 <_xor> polyex: I generally check for uid=0 and if that doesn't work then I test sudo and see if it fails.
17:12:43 <_xor> meena: I know too much about YAMLs shortcomings.
17:12:57 <_xor> I just haven't had to deal with them too much...yet.
17:14:20 * _xor has it on his to-do list to look further into capsicum, casper, and mac
17:14:29 <_xor> I don't want to have to rely on sudo when scripting stuff.
17:15:36 <_xor> ...and I'm definitely not going to setuid.
18:08:33 <rwp> _xor, Regarding signals: A typical programing bug is to trap a signal and then exit incorrectly. Either using exit code 0 or not exiting with a signal.
18:09:03 <rwp> Therefore if you are dealing with some locally constructed program from a friend I think it actually highly probably that signal handling is buggy with it.
18:09:21 <Onepamopa> Hey guys... just had one of my machines stop responding to network... logged in via IPMI only to see a "ping: sendto: No buffer space available" ... Where do I start looking for the issue?
18:09:35 <_xor> Yup, saw that in the man page and the table of the expected behavior per-signal.
18:09:46 <rwp> _xor, The ultimate work on signal handling is this: https://www.cons.org/cracauer/sigint.html
18:09:48 <VimDiesel> Title: Proper handling of SIGINT/SIGQUIT
18:10:08 <RhodiumToad> Onepamopa: netstat -m
18:10:19 <rwp> Onepamopa, Memory use in top?
18:10:40 <Onepamopa> RhodiumToad I'll add a few imgur screens here because ... ipmi
18:11:04 <RhodiumToad> Onepamopa: most likely something has used up all the mbufs, which means either there aren't enough mbufs or mbuf clusters, or something is leaking networking memory
18:12:30 <RhodiumToad> vmstat -z | grep mbuf    might also have relevant info
18:14:09 <Onepamopa> https://prnt.sc/27QtRtcsgA6d  https://prnt.sc/GYt08ywpm_9c
18:14:11 <VimDiesel> Title: Screenshot by Lightshot
18:14:51 <rwp> Do you already have trend monitoring set up such that you could look to see if something has happened before the event?  Something like Munin or other?
18:14:51 <Onepamopa> https://prnt.sc/wYhxA8ng497a
18:14:53 <VimDiesel> Title: Screenshot by Lightshot
18:15:23 <rwp> And of course if not then I suggest setting something up so that when this happens again there might be clues stored in the trend monitoring.
18:15:53 <Onepamopa> influx + grafana working collecting data about network, firewall states, etc - no spikes - everything normal
18:16:05 <Onepamopa> that's the first thing I've checked..
18:16:06 <RhodiumToad> hm. no requests for mbufs denied or delayed
18:16:12 <RhodiumToad> what OS version?
18:16:42 <rwp> Hmm...  Review the /var/log/messages log file and see if there is any clues logged there?
18:16:53 <RhodiumToad> memory allocated to network doesn't seem too excessive.
18:16:58 <Onepamopa> 13.2-STABLE 13-n255439-0bccb454ae96
18:16:59 <RhodiumToad> does ping still return the error?
18:17:02 <Onepamopa> yeah...
18:17:17 <Onepamopa> this is actually the 4th time it's happened
18:17:28 <Onepamopa> roughly takes around 20 to 30 days ....
18:18:02 <Onepamopa> now it's 46 days uptime ..
18:18:11 <RhodiumToad> hm, I don't see that commit tag, do you have some local modifications in play?
18:18:14 <Onepamopa> I've checked 4 times now and I don't see what could be causing this ...
18:18:22 <Onepamopa> yes, but nothing related to memory
18:18:52 <Onepamopa> just a small PF patch to allow me to keep the "added time" for IPs in the table when resetting counters
18:18:54 <RhodiumToad> what's the branch point between your modifications and upstream?
18:19:02 <Onepamopa> how do I check
18:19:12 <rwp> Hmm...  "swapinfo -m"??
18:19:37 <Onepamopa> used: 0
18:19:47 <rwp> Isn't that? freebsd-version -kru
18:20:21 <Onepamopa> 13.2-STABLE 3 times
18:20:23 <RhodiumToad> rwp: this is networking memory it's complaining about, which is all wired, so swapinfo isn't relevant
18:20:37 <rwp> I am not very practiced reading the network memory diagnostic data RhodiumToad has suggested by comparing those to my systems those all look very similar.
18:20:59 <Onepamopa> rwp I already compared with another machine currently working... values are ~same ...
18:21:01 <RhodiumToad> Onepamopa: git merge-base  between your branch and origin/stable/13 ?
18:21:38 <rwp> It was the 30-50 days of uptime causing problems. I have had systems where things leak memory and grow but everything seems okay until there just isn't enough resources.  Looking for things that are squeezing the system. But none are found so...
18:22:03 <Onepamopa> try 9bccb454ae96
18:22:11 <Onepamopa> 0 was a typo
18:22:36 <RhodiumToad> aha.
18:23:03 <RhodiumToad> ok, so this is -stable as of early March.
18:24:34 <Onepamopa> So.... ifconfig ix0 down && ifconfig ix0 up .... ping is finally working
18:24:35 <RhodiumToad> what type of NIC is in use?
18:24:40 <Onepamopa> but .... what was the causae...
18:24:51 <Onepamopa> intel 10gig one
18:25:51 <RhodiumToad> ixgbe driver? the one in the tree?
18:25:57 <Onepamopa> the default one
18:26:26 <rwp> RhodiumToad, How do you feel about "netstat -na | grep -e CLOSE -e FIN | wc -l" for looking for problems?
18:26:33 <kyonsalt> Onepamopa: I ever met this "no buffer space avaiable". It seems that your default route changed if you have 2+ netcards.
18:26:37 <RhodiumToad> I feel it's not relevant here
18:28:04 <rwp> I have had systems be attacked by botnets which kept network memory overwhelmed holding many resources in close wait and fin wait states.
18:28:50 <rwp> Onepamopa, Is this system on a LAN where it is relatively safe?  Or on the Internet WAN where it must fend off Internet hostilities?
18:28:57 <Onepamopa> kyonsalt It's a dual port NIC but the 2nd port has no link and I've set it "down" manually on boot.
18:29:00 <RhodiumToad> there's no indication here that network memory in total was overwhelmed
18:29:15 <Onepamopa> it's in OVH
18:29:25 <RhodiumToad> notice the number of mbufs and clusters in use was not excessive and there were no counts for mbuf requests delayed or denied.
18:29:39 <Onepamopa> and no intr queue drops
18:29:53 <RhodiumToad> that bouncing the interface fixes it suggests that the problem was it failing to enqueue packets to the hardware
18:30:33 <RhodiumToad> the driver itself doesn't seem to mention ENOBUFS, but it's an iflib driver and iflib can return that in some cases.
18:31:07 <Onepamopa> you're suggesting a driver issue or hardware failure ?
18:33:25 <RhodiumToad> there's some changes to ixgbe and iflib since March, but nothing that seems obviously relevant
18:34:05 <RhodiumToad> these days distinguishing between "driver bug" and "hardware bug" can be rather ... vague
18:37:16 <rwp> I am suspicious it might be a high network load caused by external agents. A botnet for example.
18:37:21 <RhodiumToad> I've not used this hardware myself, so I don't know whether it's worth trying the port drivers
18:37:21 <rwp> Bringing the interface down will flush all internal resources, and then up will reestablish connectivity. And the network disruption _might_ cause abusive attackers to disconnect and move to the next IP address.
18:39:01 <rwp> Since the Internet packet lifetime is 2 minutes I have in the past downed interfaces for 2 minutes to force all network connectivity to fail off as a temporary brute force hack to nudge attacking botnets to move on to another IP address.  It's a hack though I admit.
18:39:32 <Onepamopa> rwp let me show you ... https://prnt.sc/dyAOM_Yui0yW
18:39:33 <VimDiesel> Title: Screenshot by Lightshot
18:39:51 <Onepamopa> does that look like a ddos to you? because it doesn't to me...
18:40:02 <Onepamopa> this is the past 3 hours, 1 second resolution
18:40:42 <Onepamopa> so.. let's get back to figuring what's causing this...
18:41:10 <rwp> Very good that you have trend data!  Does not look like an attack to me from that data.  It looks like everything is okay.  Right up until it isn't.  And then it's wedged.
18:41:23 <Onepamopa> exactly
18:43:35 <rwp> At least with it back on the net you can log in using ssh instead of needing ipmi and be a little more comfortable.
18:43:39 <rwp> Since you haven't found a specific problem I would fish further out and look through all of the logs of anything this system is doing.  If it is Nginx then I would look through those logs looking for clues.  And so on for whatever it does.
18:43:52 <Onepamopa> I've already ssh'd in and even placed some traffic back on it
18:44:24 <Onepamopa> rwp I've already done that and haven't found anything to indicate even remotely of an issue
18:44:46 <Onepamopa> which is why, even though I'm super tired and sleepy - I went here to get some help in figuring this..
18:45:18 <Onepamopa> because, as I said.. it's the 4th maybe even 5th time this is happening, and each time I'm pulling the latest src, compiling kernel and world, installing, doing a fresh reboot and placing traffic back
18:45:20 <rwp> Tricky problem!  I always hate it when there are few clues to what might be the problem.
18:45:25 <Onepamopa> and 30-40 days after that - whoa - it happens again
18:45:51 <rwp> It happens to this one specific system?  Or it happens to any of your systems?
18:46:17 <Onepamopa> it's happened on multiple systems
18:46:32 <RhodiumToad> all with this same nic?
18:46:37 <Onepamopa> most often on this one because it's most loaded
18:46:40 <Onepamopa> yes
18:46:47 <Onepamopa> all ryzen 9s with 10gig nic
18:46:51 <Onepamopa> in different datacenters
18:46:53 <rwp> I would have a hard time thinking it is a hardware failure if it is happening on multiple different hardware systems.  But could still be a driver issue.
18:47:06 <Onepamopa> could be but ... who can tell for sure ?
18:47:12 <Onepamopa> I certainly can't ..
18:48:41 <rwp> After search the wisdom of the web for this problem there are an amazing number of hits on people reporting the same problem and they mostly say ifconfig down and then up resets them back to working and then the trail ends.  I assume it is a temporary reset and not a permanent fix though.
18:49:40 <Onepamopa> so... if any of the devs lurk around anonymously... make yourselves known :)
18:51:02 <rwp> JFTR but are these systems running a pf or ipfw firewall?  Just gathering data...
18:52:55 <meena> rwp: 19:18 <Onepamopa> just a small PF patch to allow me to keep the "added time" for IPs in the table when resetting counters
18:54:15 <rwp> Thanks meena!  I had not seen that in the scrollback.
18:57:06 <meena> it only registered peripherally and tingled my spidey sense, because I believe to remember seeing a bug or thread about memory leaks in pf
18:57:23 <meena> but i can't look it up now, really
18:58:53 <rwp> Onepamopa, Since you have already taken the interface down/up reseting things and it is late time in your timezone and you say you are exhausted if it were me I would be inclined to sleep now and then hit it fresh with a clear head tomorrow. Since probably that reset restarts the 30-40 day clock I would expect things will continue through the night into morning okay. Since you have explored everything you/we can think of at this time.
19:00:24 <Onepamopa> meena the patch is basically a single if () to not re-set the time of the IP when table counters get flushed
19:00:53 <Onepamopa> If you think that can cause a memleak ... it would've happened a lot sooner I think.. not after 30-40 days
19:04:03 <RhodiumToad> I don't think it's a memory leak as such
19:24:06 <meena> Onepamopa: i didn't mean your patch is causing that
19:24:13 <Onepamopa> oh..
19:24:58 <Onepamopa> I'm really out of ideas.. the only thing I can do is pull the latest, rebuild all and hope it won't happen again
19:26:33 <Onepamopa> but considering I've been doing that 4-5 times now ...
19:30:55 <RhodiumToad> have you tried the port drivers?
19:31:03 <Onepamopa> no
19:31:19 <Onepamopa> what do I try ?
19:31:44 <Onepamopa> compile ixgbe driver from ports instead of using the one in the kernel ?
19:32:00 <RhodiumToad> take a look at net/intel-ix-kmod in ports
19:32:15 <RhodiumToad> check the descriptions for whether your card is supported
19:32:42 <RhodiumToad> I haven't used this hardware so I have no personal experience with it
19:33:07 <Onepamopa> hm, kldstat shows its using if_igb
19:34:55 <RhodiumToad> what does it show exactly?
19:35:23 <Onepamopa>  5    1 0xffffffff8215c000    74f30 if_igb.ko
19:36:35 <Onepamopa> link at 1g media: Ethernet autoselect (1000baseT <full-duplex>)
19:37:27 <RhodiumToad> what does pciconf -lv  show for the device?
19:38:19 <Onepamopa> Ethernet Controller X550
19:38:31 <RhodiumToad> the whole output pleaser
19:38:37 <RhodiumToad> s/r$//
19:38:38 <Onepamopa> ix0@pci0:1:0:0: class=0x020000 rev=0x01 hdr=0x00 vendor=0x8086 device=0x1563 subvendor=0x1849 subdevice=0x1563
19:38:39 <Onepamopa>     vendor     = 'Intel Corporation'
19:38:39 <Onepamopa>     device     = 'Ethernet Controller X550'
19:38:40 <Onepamopa>     class      = network
19:38:40 <Onepamopa>     subclass   = ethernet
19:39:44 <RhodiumToad> do you have anything explicitly loading an if_igb? e.g. in loader.conf or kld_list in rc.conf
19:40:08 <Onepamopa> yes
19:40:11 <Onepamopa> @ loader
19:40:58 <Onepamopa> it's from an older server, i'll remove it
19:41:51 <RhodiumToad> that's the em driver, which shouldn't be applicable to an x550 card
19:41:56 <Onepamopa> Id Refs Address                Size Name
19:41:56 <Onepamopa>  1   65 0xffffffff80200000  1f42b38 kernel
19:41:57 <Onepamopa>  2    1 0xffffffff82143000    11ab8 ipmi.ko
19:41:57 <Onepamopa>  3    3 0xffffffff82155000     3cb0 smbus.ko
19:41:58 <Onepamopa>  4    1 0xffffffff82159000     2870 accf_data.ko
19:41:58 <Onepamopa>  5    1 0xffffffff8215c000    74f30 if_igb.ko
19:41:59 <Onepamopa>  6    1 0xffffffff821d2000    716f8 pf.ko
19:41:59 <Onepamopa>  7    1 0xffffffff82244000     ab70 opensolaris.ko
19:42:00 <Onepamopa>  8    1 0xffffffff8224f000     2e88 accf_http.ko
19:42:00 <Onepamopa>  9    1 0xffffffff826e5000     3378 acpi_wmi.ko
19:42:01 <Onepamopa> 10    1 0xffffffff826e9000     3218 intpm.ko
19:42:01 <Onepamopa> 11    1 0xffffffff826ed000     3380 if_urndis.ko
19:42:02 <Onepamopa> 12    1 0xffffffff826f1000     3178 uether.ko
19:42:02 <Onepamopa> 13    1 0xffffffff826f5000     3340 uhid.ko
19:42:03 <Onepamopa> 14    1 0xffffffff826f9000     4350 ums.ko
19:42:03 <Onepamopa> 15    1 0xffffffff826fe000     3380 usbhid.ko
19:42:04 <Onepamopa> 16    1 0xffffffff82702000     32b0 hidbus.ko
19:42:04 <Onepamopa> 17    1 0xffffffff82706000     54b8 if_gre.ko
19:42:06 <RhodiumToad> paste site!
19:42:31 <RhodiumToad> no if_ix there?
19:42:41 <Onepamopa> https://bsd.to/Btpk
19:42:43 <VimDiesel> Title: dpaste/Btpk (Plain Text)
19:42:47 <Onepamopa> nop...
19:42:53 <RhodiumToad> does kldstat -v  show if_ix loaded as part of kernel?
19:43:48 <Onepamopa> https://bsd.to/cpE0
19:43:50 <VimDiesel> Title: dpaste/cpE0 (Plain Text)
19:44:14 <RhodiumToad> ok, pci/ix is it
19:44:44 <RhodiumToad> are you using GENERIC or a custom kernel config?
19:44:48 <Onepamopa> generic
19:45:31 <RhodiumToad> device ix  is in the GENERIC config, so that's ok
19:46:13 <RhodiumToad> I don't _think_ loading igb will have been doing any harm, it just shouldn't be attaching to anything
19:46:39 <RhodiumToad> certainly not necessary though.
19:46:55 <Onepamopa> I've already removed it from loader
19:47:13 <Onepamopa> so, you suggest I build the ix driver from ports and manually load it on boot?
19:47:51 <RhodiumToad> I don't recommend that you do it or don't do it, it's just one option you might try
19:48:25 <Onepamopa> is that driver newer than the one in the kernel?
19:48:45 <RhodiumToad> I don't know, you could check that. All I know is that it exists
19:55:57 <Onepamopa> hm, the kernel ix driver is char ixgbe_driver_version[] = "4.0.1-k"; the port is 3.3.10 ?
22:35:47 <polyex> is there such a thing in a shell script as getting a tmp dir generated that i can use then delete after script is done?
22:41:20 <VVD> polyex, mktemp(1)?
22:54:11 <polyex> wtf it's perfect!!!
23:07:56 <BillyJoeBob> Hello, all.
23:08:03 <polyex> in a shell script being run by sudo i don't suppose there's any way to get the $HOME of the user calling sudo myscript?
23:08:07 <polyex> heya
23:18:19 <polyex> when i make a scripted bsdinstall out of an extracted iso, i put my custom.txz distribution in usr/freebsd-dist. but trying to do the same thing from src, when i build and installworld installkernel somewhere, there's no freebsd-dist dir. so where do i put my custom.txz?
23:21:20 <dh> polyex: sudo by default exports SUDO_xxx environment variables to executed program, for example SUDO_USER which you can use to determine the home directory of the caller
23:23:40 <polyex> like some command like mktemp that i can call with $SUDO_USER to retrieve its $HOME?
23:27:31 <satanist> getent passwd "$SUDO_USER" |cut -d ':' -f 6
23:38:40 <polyex> weird but cool ty
23:39:46 <polyex> how do i do a conditional check in bash? if ["$(id -u)" -ne 0]; then... doesn't run when i execute it as non-superuser. how can i make it work right?
23:41:11 <polyex> wow i just needed spaces between the [] !
23:46:57 <rwp> The [ square bracket is a built-in alias for the "test" operator.  if test"$(id -u)" -ne 0 would not work either and also needs a space.
23:47:31 <polyex> oh wow
23:49:26 <rwp> Try "man [" for example.  The "[" is just a command but happens to be builtin for performance reasons.  But it must be treated as if it were an external for all purposes of quoting and passing arguments.
23:53:39 <rwp> Meanwhile...  | & ; ( ) < > are metacharacters and special to the shell individually and don't need spaces. They separate words. If used plainly they must be quoted.
23:57:06 <rwp> Meanwhile... ! { } are shell keywords.  Used for negation and lists.  Being a keyword they need spaces.  So { echo foo ;} is a list. But {} is not { nor } but {} and does not need quoting. This confuses people routinely when using find's -exec echo {} + sequence and I often see people quoting it like "{}" "+" which is unnecessary extra superfluous and redundant quoting.
23:57:44 <polyex> i kinda don't like symbols being so different
23:57:51 <polyex> am i alone thinking that's mentally taxing?
23:58:21 <rwp> It all evolved that way back in the 1970's and changing it after all of these years would break a lot of stuff.  Best not to stir the pot.