01:35:17 <skered> I see people doing it by hand but is there a reason something like iocage or ezjail don't have an arch. option?
01:36:52 <skered> ex: I want a 32-bit jail on a 64-bit host.
01:40:02 <meena> skered: both of those are longer maintained
01:41:10 <skered> ezjail I knew but it works.  iocage I thought as the replacement...  What's the new jail manager?
01:46:56 <meena> https://wiki.freebsd.org/Containers
01:46:57 <VimDiesel> Title: Containers - FreeBSD Wiki
01:50:01 <meena> skered: bastille, cbsd, and pot are probably the best candidates on that list
01:50:57 <meena> but, if you got like 5 jails, instead of 50-500, you might also just consider jail.conf
01:51:40 <meena> https://alpha.pkgbase.live/howto/jails.html is how i do it
01:51:41 <VimDiesel> Title: Howto: Setting up Jails
01:51:47 <skered> Like by hand?  yuck.
01:52:17 <meena> eh, I've done worse
01:52:50 <meena> like written my infrastructure automaton in Perl and then rewritten it in gnu make
01:53:57 <meena> but right now, I've literally got four jails, and until i get buildah and podman working, I'll be doing it like this
01:56:51 <skered> We don't use those words in #freebsd.  🤫
04:18:26 <Plasmoduck> hey, everythime I installed freebsd 1 on my thinkpad x1 carbon I would get the intel speed shift bug and the system would hang. So I added something to my loader.conf to set it off
04:18:43 <Plasmoduck> but now the system gets really hot and freezes
04:18:55 <Plasmoduck> so I disabled it again and now my computer wont even boot
04:19:03 <Plasmoduck> isnt there a fix for this by now
04:19:13 <Plasmoduck> 13.1-release
04:22:24 <Plasmoduck> now I have to format and start over again
04:22:31 <Plasmoduck> sucks to be stuck on 12.*
04:28:57 <johnjaye> any tips on speeding up the boot time? i need to cut it from 2 minutes in this vm to 1 minute if possible.
04:29:34 <johnjaye> i put autoboot_delay=1 in /boot/loader.conf and rc_startmsgs=NO into /etc/rc.conf
04:30:00 <johnjaye> i googled it but i'm not sure which suggestions make sense or don't make sense. one of them said to start commenting out random 'sleep 1' lines from startup scripts
04:52:52 <mason> johnjaye: A minute seems a bit long. What's taking the time?
04:53:45 <johnjaye> well it's a vm and it's slow
04:54:02 <johnjaye> if i switch the arch and enable kvm it should improve. but i don't care about speed just about starting it
04:54:37 <johnjaye> qemu has this annoyance where even if you suspend the guest inside its monitor it still eats up cpu time on the order of a web browser. i could just suspend the process i suppose
04:55:18 <mason> What's the host?
04:55:45 <johnjaye> the raspi4 i'm typing this on. i wanted to start a local freebsd instance on it for a project
04:56:25 <mason> Oh. Opportunities for things to go slow abound there.
04:57:06 <johnjaye> indeed. but i'm not familiar enough with how freebsd starts up to go any further
04:57:34 <johnjaye> the thing is there is not a 'standard' way to start up on arm, so i'd have to google around for the right params for that to work...
04:58:12 <johnjaye> i can try the freebsd wiki's suggestion and hope for the best though
05:02:39 <Plasmoduck> this whole intel speed shift bug is rediculous
05:02:56 <Plasmoduck> I've managed to boot old kernel and disable it again
05:14:30 <johnjaye> starting devd sure takes awhile...
05:14:38 <johnjaye> but not as long as the network!
05:26:42 <doug713705[m]> Plasmoduck: same here with a Lenovo p14s gen1. I read somewhere (can't remember where) that it is fixed in 14.0. I'm waiting, just hoping the fix to be backported to 13.2
05:29:17 <johnjaye> well it's down to 24 seconds using qemu with -cpu max. very confusing.
05:29:53 <johnjaye> if i tell it -cpu cortex-a72 then qemu refuses to start at all. but with -cpu host or -cpu max it boots freebsd on aarch64 in 30 seconds. then if i ask freebsd its cpu it says cortex-a72 r0p3
05:30:08 <johnjaye> well that doesn't make sense but at least it's fast now
05:32:13 <johnjaye> to be clear the raspi4 has cortex a72's in it... so idk the conflict here
06:02:39 <Plasmoduck> doug713705[m]: yeah its crazy
06:03:04 <Plasmoduck> on top of that, something is causing my system to freeze/lock up
06:03:18 <Plasmoduck> some software I updated before upgrading to 13
06:03:25 <Plasmoduck> it's driving me crazy
09:50:55 <zapata> doug713705[m]: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253288 ? It's already in stable/13 and releng/13.2.
09:50:57 <VimDiesel> Title: 253288 – hwpstate_intel: modern ThinkPads wedge under any kind of load or during boot
09:51:47 <doug713705[m]> zapata:  Thank you for the good news :)
10:19:32 <parv> (Took some time to read the PR) zapata, same here
10:42:35 <pertho> anyone here use node_exporter on FreeBSD for prometheus stats? I am seeing this constantly: node_exporter[13044]: ts=2023-02-25T15:03:20.906Z caller=collector.go:169 level=error msg="collector failed" name=meminfo duration_seconds=8.8323e-05 err="couldn't get memory: cannot allocate memory"
10:44:17 <Remilia> pertho: is that in syslog?
10:44:22 <pertho> Remilia: yes
10:44:36 <Remilia> I do not have anything like that
10:45:18 <Remilia> using node_exporter, version 1.3.1 (branch: release-1.3, revision: 6)
10:45:57 <pertho> node_exporter, version 1.5.0 (branch: release-1.5, revision: 1)
10:47:30 <Remilia> hhmm
10:47:49 <pertho> I guess I could just add --no-collector.meminfo to the cmdline
10:48:04 <pertho> prometheus doesn't seem to draw the memory info properly for a freebsd client anyway
10:52:22 <pertho> adding node_exporter_args="--no-collector.meminfo" to /etc/rc.conf fixes it but disables any memory info.. not that prometheus/grafana seem to show it which is odd
10:55:22 <pertho> not the first time it broke I guess: https://github.com/prometheus/node_exporter/issues/1344
10:55:24 <VimDiesel> Title: meminfo collector broken on FreeBSD · Issue #1344 · prometheus/node_exporter · GitHub
10:55:25 <VimDiesel> 1344 – pstat -i wasn't documented on the man page https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=1344
10:55:50 <pertho> https://github.com/prometheus/node_exporter/issues/2593 <- latest one
10:55:52 <VimDiesel> Title: FreeBSD: couldn't get memory: cannot allocate memory · Issue #2593 · prometheus/node_exporter · GitHub
10:55:52 <VimDiesel> 2593 – [small] security hole and nfs compatibility bug in rexecd.c https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=2593
10:57:04 <Remilia> pertho: hmm I updated mine just now to 1.5
10:57:18 <Remilia> not seeing any errors currently
10:57:29 <Remilia> but it has only been 5 minutes
10:59:14 <pertho> 1.5.0 is definitely broken.. the fix was committed 2 weeks ago.. but 1.5.0 came out end of November 2022 :/
10:59:46 <pertho> wonder if that could be backpatched into the FreeBSD port.. hmmm
11:00:08 <pertho> if portsnap is going away.. what's replacing it?
11:05:49 <pertho> ah ha.. this may have been fixed in 1.5.0p3
11:05:54 <pertho> I'm on 1.5.0p1
11:18:16 <pertho> Remilia: node_exporter-1.5.0_3 fixes it! :)
11:29:56 <pertho> am I correct in assuming this commit is for -CURRENT (14.0?) and not 13.1? https://svnweb.freebsd.org/base?view=revision&revision=362631
11:29:57 <VimDiesel> Title: [base] Revision 362631
11:35:38 <meena> pertho: that's two years old. chances are it's in 13.0
11:36:04 <V_PauAmma_V> Per https://www.freebsd.org/security/unsupported/ , -current was still 13-current, ie before ... beat me to it.
11:36:05 <VimDiesel> Title: Unsupported FreeBSD Releases | The FreeBSD Project
11:37:12 <pertho> still seeing loads of these messages: kernel: linux: jid 0 pid 1456 (VizCompositorTh): possibly incorrect MADV_DONTNEED
11:37:23 <dch> pertho: https://cgit.freebsd.org/src/log/sys/compat/linux/linux_mmap.c?h=releng/13.2
11:37:33 <dch> you can look through there for it
11:37:39 <dch> maybe git blame etc
11:38:32 <pertho> hmm.. I'm on 13.1-RELEASE-p7
11:39:49 <meena> https://freshbsd.org/freebsd/src/commit/05e842d8294bb4c98664ef8ef689b0caf24b5112 it's in 12.2
11:39:50 <VimDiesel> Title: FreeBSD / src / 05e842d8294bb4c98664ef8ef689b0caf24b5112 - FreshBSD
11:40:36 <meena> https://freshbsd.org/freebsd/src/commit/362631
11:40:37 <VimDiesel> Title: FreeBSD / src / 362631 - FreshBSD
11:42:09 <pertho> hmm.. that revision (362631) may not fix the messages
11:44:37 <pertho> ah well.. wait for 13.2 at the end of next month then :D
11:59:14 <meena> pertho: test beta / stable now, test current, demand fixes from current
12:33:47 <Remilia> pertho: oh, makes sense, it was 'node_exporter: 1.3.1_6 -> 1.5.0_3' for me
15:21:30 <dch> welp
15:21:37 <dch> `BTX halted` on boot
15:21:51 <dch> I'm in the middle of migrating cluster node 3/3 to new h/w
15:22:00 <dch> and thats cluster node 2/3 crapping itself
15:22:11 <dch> which leaves ... 1 of 3 nodes which is not quorum :-(
15:25:44 <dch> I have backups, but damn that timing is awkward
15:26:21 <drobban> :-|
15:29:49 <drobban> dch: do you have any clue to why?
15:30:29 <dch> not really. `BTX halted` is ~ probably ~ the first boot sector or two on the SSD mirror
15:31:11 <dch> but these are UEFI boxes so something happened that has borked both NVMes to the point it cant boot
15:31:24 <dch> so my guess is a h/w fault, maybe backplane or something
15:32:49 <drobban> you said new hardware... is it "same" kind of hardware or is the any diff in controllers sata/raid and so on
15:32:57 <drobban> there*
15:33:40 <dch> oh so this node has died while I'm migrating / upgrade *another* node
15:33:53 <dch> completely different h/w / vendors / locations
15:34:02 * dch spins up a replacement node
15:37:19 <dch> gonna turn this bad one off for 10m maybe it just got too warm for its own good
15:37:39 <drobban> :/ could always hope
18:01:16 <dvl> I am repeatedly being stumped by a syncoid hosta:system/data localsys/data "cannot create snapshots : permission denied" errors.  I keep checking permission, wondering, why, the others work fine. After about 10 minutes of trial and error I remember: the source filesystem is jailed. I must do a 'zfs jailed=off` first....
18:10:06 <dch> dvl: that is so annoying, every time I run into it
18:10:37 <dvl> Don't be like me. Think jailed first, then permissions.
19:43:44 <vext01> what do you folks use to get notifications about zfs failures?
19:43:50 <vext01> no zed on fbsd it seems
19:44:02 <vext01> nfsd man page doesnt say anything about notifications
19:44:14 <vext01> some vague mutterings on the internet about devd something something
19:44:48 <vext01> silly that `zpool status -x` isn't silent when all is well, or you coudl stick it right into a cron job
19:53:54 <parv> Well, there is "-n" option, at least in 13.1, to send mail when the command exits with 0 code
19:54:08 <parv> 1 2 * * * -n zfs status
19:55:14 <parv> Let me try that again. "crontab(5)" has "-n" option, at least in 13.1, to not send mail when the command exits with 0 code
19:55:16 <otis> there also is zfsd
19:55:52 <vext01> above when i said nfsd, i meant zfsd, sorry
19:56:13 <vext01> can it do email notifications? man page is a little sparse
19:56:53 <vext01> also the man page doesnt document the return status of any of the userspace zfs tools
19:57:44 <parv> That lack should be filed as (document) bugs
19:59:12 <vext01> parv: agreed
19:59:38 <vext01> where to? openzfs i guess
20:02:55 <meena> https://github.com/openzfs/zfs/tree/master/man
20:02:57 <VimDiesel> Title: zfs/man at master · openzfs/zfs · GitHub
20:03:12 <meena> I liked thru a few, didn't see any exit codes
21:19:42 <debdrup> vext01: zfsd will generate system messages which get handled by syslogd just like any other daemon with system logging capability, which has been a thing on Unix-likes for decades.
21:21:01 <rtprio> vext01: i set a script to run `zfs status` and send me a push notificatin if it differs from the last `zfs status`
21:21:40 <rtprio> it's pretty simple, i didn't want to wire it into syslog
21:24:06 <debdrup> You _do NOT_ under any circumstances want to rely on email for notifications about storage (or anything else) failing, because email isn't a reliable delivery protocol.
21:25:38 <epony> what is more reliable for you then? ;-) irc?
21:26:04 <epony> (discover the power of syslog)
21:26:14 <debdrup> There's plenty of tools that're made to solve this problem, including but not limited to zabbix, prometheus, librenms and many others.
21:28:41 <debdrup> epony: if email isn't reliable, irc sure isn't.
21:29:16 <rtprio> apis to push services, like pushover or pushbullet aren't bad at a small scale
21:29:45 <pertho> or.. *shiver* ... Slack
21:30:46 <debdrup> If you read the RFCs for SMTP, the closest you'll get to "reliability" is that the server shouldn't "lose mail for frivalous reasons" (or something to that effect).
21:31:10 <debdrup> That's an actual RFC using language _that_ nebulous, so you know it's bad. :P
21:32:37 <epony> some people use XMPP like sendmail too
21:33:07 <epony> but store and forward is more reliable than sent and "lost"
21:45:14 <debdrup> There's no real point in listing all the bad ideas people have had, because they'll keep having them at a rate that far exceeds any reasonable way of enumerating them :P
21:47:23 <parv> :-)
22:05:32 <vext01> debdrup: email is more reliable than relying on me to learn any of those tools :P
22:06:26 <vext01> rtprio: thanks, i like that
22:06:41 <vext01> might just write a script that sends a diff
22:20:04 <debdrup> Yes, what do I know, I've only been in storage, network, and systems administration for a few decades.
22:20:19 <vext01> :)
22:20:28 <vext01> such noob, wow
22:24:28 <ngortheone> I think there is a confusion between monitoring and alerting, and their componenets. Nobody argues that dedicated monitoring application like zabbix is a good tool for detecting problems in the system. But how does zabbix do alerting?
22:25:08 <ngortheone> It can show you the error on the dashboard, but this is not alering. It can send an email, sms, push notification, call an http endpoint..
22:25:26 <ngortheone> As with any network communication there is a chance of failed delivery
22:26:18 <ngortheone> But even if the alert has failed to reach the destination, the even will not be lost, it will be stored in zabbix database somewhere and you will see on the dahboard
22:26:51 <parv> Install a bell & apppoint person to send a courier to hit appropriate person with clue fish
22:26:55 <ngortheone> Prometheus is not a complete monitoring or alerting solution, so but it can be a part of one
22:27:47 <ngortheone> parv: yes :) but a courier can get hit by a bus
22:28:32 <parv> .oO(Man! All these damn exceptions)
22:28:56 <ngortheone> I'd say that no single channel is reliable. By combining different channels together and using them as fallbacks for each other is the closes you get for relaibility
22:29:39 <ngortheone> including a bell and a buttler with an evelope on a tray
22:31:42 <ngortheone> I think what debdrup was trying to say is that "don't just fire off an email in a script that detected a problem"
22:32:27 <ngortheone> because if this email gets lost you will loose the trace of a problem
22:32:41 <ngortheone> first - save the event in some sort of database
22:33:00 <ngortheone> and then let a separate agent worry about delivering an event
22:33:40 <ngortheone> zabbix does it for you, many other solutions do too
22:37:31 <meena> I have people on IRC message me when https://alpha.pkgbase.live/ falls over, or its certificate runs out…
22:37:32 <VimDiesel> Title: Unofficial FreeBSD pkgbase repository
22:37:40 <meena> that's monitoring and notification outsourced…
22:38:59 <ngortheone> after certain point this stops serving you well. One of my favorite ways to get AWS fix their shit is to post about broken thing on twitter
22:39:06 <ngortheone> works better then paid support
22:39:07 <meena> you might notice that I've burned out on systems administration, but if you haven't, a nice monitoring system (not nagios) will bring you … uh.… something.
22:39:36 <meena> ngortheone: my twitter accounts are emptied and set private
22:40:30 <meena> ngortheone: it's just one service, and getting feedback gives me a feeling for how many people use it / rely on it.
22:40:39 <meena> which i think is ca 5.
22:40:44 <ngortheone> not the point, I was trying to say that service interrup notification relayed over public channels damage your reputation
22:41:03 <ngortheone> you may not care about it atm, but when you are a size of Amazon you can't afford it
22:41:18 <ngortheone> twitter in general is a bad,bad place
22:50:05 <meena> ngortheone: it's a service used by 5 people, and it has Alpha in the name and title and description
23:04:07 <ngortheone> sometimes I think that POSIX was written by predators for aliens
23:04:19 <ngortheone> check this: (man 3 daemon)
23:04:27 <ngortheone> Unless the argument noclose is non-zero, daemon() will redirect standard input, standard output, and standard error to /dev/null
23:04:48 <ngortheone> double-negation, unless.. non-zero
23:05:04 <ngortheone> who writes docs like that?
23:06:37 <xtile> daemon isn't even in POSIX, that's a FreeBSD man page
23:06:39 <ngortheone> they could've called the argument "keep_open" and say - "keep_open >=1 keeps file descriptors open, if == 0 then file descriptors are redirected to /dev/null"
23:06:55 <ngortheone> well, it exists in Linux too
23:07:03 <xtile> yeah?
23:07:04 <ngortheone> with the same description and argument tames
23:07:15 <ngortheone> https://man7.org/linux/man-pages/man3/daemon.3.html
23:07:16 <VimDiesel> Title: daemon(3) - Linux manual page
23:07:33 <xtile> it's a BSD function that GNU/Linux adopted, then. :P  Not POSIX.
23:07:55 <ngortheone> Linux actually has slightly better description
23:08:09 <ngortheone> "If noclose is zero, daemon() redirects standard input, standard output, and standard error to /dev/null; otherwise, no changes are made to these file descriptors."
23:08:10 <ngortheone>  
23:08:34 <ngortheone> which avoids mental gymnastics required to figure out the double-negated sentence
23:08:44 <xtile> agreed, this is a better description
23:08:48 <xtile> the one in the gnu/linux man page
23:10:17 <ngortheone> well, ok, dis on POSIX was unfounded... this time :D
23:10:32 <xtile> OpenBSD has removed the double negation, but NetBSD and DragonFlyBSD retain the double negation in their man pages
23:10:40 <xtile> https://man.openbsd.org/daemon.3
23:10:41 <VimDiesel> Title: daemon(3) - OpenBSD manual pages
23:11:24 <ngortheone> yeah, we can do even better -> rename noclose argument to keepopen
23:11:45 <ngortheone> then description makes sense: keepopen == 0 -> /dev/null
23:12:00 <ngortheone> otherwise..well keep those descriptors open
23:12:15 <xtile> gonna break someone's code? :3
23:12:30 <ngortheone> unfortunately..
23:12:34 * xtile nods.
23:15:28 <xtile> ngortheone: submit a patch for the man page :D
23:15:36 <xtile> i wouldn't mind seeing the wording changed to how OpenBSD's has it
23:15:38 <ngortheone> already on it
23:15:39 <xtile> it would read better
23:15:41 <xtile> nice
23:15:44 <xtile> thank you <3
23:16:05 <ngortheone> trying to locate the man page
23:16:22 <xtile> /usr/src/lib/libc/gen/daemon.3
23:16:28 <xtile> the 'locate' command works well
23:17:08 <xtile> it's installed to, of course:
23:17:10 <xtile> /usr/share/man/man3/daemon.3.gz
23:17:18 <ngortheone> Thanks! Found it
23:22:33 <ngortheone> https://github.com/freebsd/freebsd-src/pull/671
23:22:34 <VimDiesel> Title: man 3 daemon: remove double negation by ngortheone · Pull Request #671 · freebsd/freebsd-src · GitHub
23:23:30 <xtile> I approve of this, including the 'will redirect' -> 'redirects'
23:23:51 <ngortheone> openbsd did so too
23:24:00 * xtile looks again, and notices now.
23:24:11 <ngortheone> I took their text verbatim