By the time of late 3.x and 4.x I had a parallel port Zip drive and floppies with bad blocks, save the boot disk were history.

4ish and later I had a CD drive with its own ISA card interface.

And FreeBSD Mall was a think along with Walnut Creek's store front that did more than FreeBSD CD sets iirc.

was free built off the tailwinds of BSD or did it carve its own path?

What's policy of FreeBSD on non-free software?

what do you mean policy?

run non-free software if you want to run it

I would like to avoid non-free software

then do so

ok, then don't install it? what is the question

Usually in Linux distros package managers you can disable/enable non-free repositories to avoid accidental injection of non-free dependencies. And I wonder how is it in FreeBSD.

there are some switches in the ports tree to refuse to build ports of a particular license

you can look into that, if that's a path that would bring you joy

mlxdy2, or you could check whether that software is free or not before installing?

there's no functionalty on the pkg repo for a license excluder

rtprio Oh, okay

free vs not-free is really a social issue. you can't fix social issues with technology

who said anything about fixing social issues. not installing software just doesn't install software. don't read too much into it

DoofusCanadensis, license preference is also a social issue.

maybe thats the problem

it should be a software technical question

Where humans are involved, morality is involved. Software licneses have a moral aspect to them.

what are you doing, what is it, who can change it, and who can sell it

now you just need a a measure for "moralaity"

but generally I agree

The lack of an absolute measure of it makes us humans :-)

Hello I have a FreeBSD 15.1 server w/ 192GB RAM running bhyve and sylve GUI for 20 VMs. Every morning at 3am the server crashes. It seems that by default the daily cronjob for each VM and the server runs at the same time, overconsuming all of the RAM without releasing it, leaving only ~4gb RAM causing it to crash. I have another FreeBSD server (15.0 p9) with similar configurations but only 5 VMs and have not experienced any errors. The malfunctioning

server states processes are killed due to a failure to reclaim memory. is anyone aware of any possible bugs or any insight I would appreciate, thanks!

Are you using zfs?

ZFS' arc cache can use up a lot of memory

192G ram, must have cost a fortune

I have this setting in my /etc/sysctl.conf on my 128GB server: vfs.zfs.arc.max=34359738368

And a slightly larger setting on the 512GB server. Both had problems of oom killer killing bhyve processes randomly before tuning this setting

If your cronjob traverses the filesystem, that could contribute to ZFS needing more and more memory

do you need periodic to run in those VMs

Or on the host

yes i use zfs, for which i have a 4tb nvme and a 4tb spinning drive. but all the machines are sitting on nvme. normally all the machines don't use >16gb RAM, so the remaining should have been plenty to handle the periodic daily cronjobs

mary751: you can also tune cronjobs to have jitter, look into "-j" and "-J" (man 8 cron)

to be honest i think perioidc is a double-edged sword. it can really swamp a machine. esp if run on a host with many jails.

bsdrobert: I have to learn the benefit of that periodic run in VMs but again, my other server with less VM's also configured identically does not run into these errors

bsdrobert: been there, done that, now I use 30sec jitter for my cronjobs everywhere

karolyi:thank you I have not heard about jitter I will have to look into it. I manually staggered the daily cronjobs in three different batches at different time intervals but it does not seem the memory gets cleaned after periodic daily runs

tuning the ARC by hc's suggestion might also be a good idea

hc: that is very helpful, thank you, I am using zfs and have not limited the arc size. I need to learn more about how cronjob traverses filesystem (by the way, my host has zfs and the VMs are zfs). anything else I could look into?

mary751: Not really; the one I mentioned is the one setting that I needed to adjust on all my FreeBSD bhyve hosts. Since FreeBSD switched its zfs implementation to the zfsonlinux one, the kernel sometimes cannot communicate quickly enough to the zfs subsystem that it needs more memory

With that setting you're limiting it proactively

the periodic does a lot of stuff, if you don't need security reports within your VMs, turn them off. there is a security report and a daily report that will traverse all your files, checking for possible security issues, reports that normally only few people read

karolyi: alright I need to get educated on what periodic security reports looks like, I don't even know where they are located. Can netdata view them, or do i need to view them manually, or web interface, or just text?

mails to root by default iirc.

I can imagine how those simply overload ZFS if you have a lot of them running at the same time

( With "not really" I meant I can't think of anything else, not that there isn't anything else )

mary751: cat /etc/crontab, ls /etc/periodic/

thanks so much guys I'll be back in an hour or so

my jail template basically comments out everything in the crontab so the jails don't hammer my server, and then I enable things on a custom basis. some jails don't even have cron running

just some ideas to ponder on

The zfs cache is very memory hungry, it basically uses all of the available free memory. Kind of like the idle process uses up all idle cpu time. If the zfs cache doesn't release the memory quickly enough, well...

But I've never heard of zfs getting 'overloaded'

i lean towards just turning periodic off. it doesn't have defaults that scale.

hc: imagine 20 VMs doing it independently of each other at the same exact time

it can easily become an OOM in my opinion

karolyi: Why? Are the VMs overprovisioned? If not, should be fine

hc: that's not a question I should answer. :)

It wasn't mentioned in the initial question so I take it that is not the case

then again, overprovisioning is relative to what else you have running at the same time

for example, you might have provisioned the VM's memory allocations well but the periodic run on the host machine can spike ARC usage and then all of a sudden, OOM

who knows to be honest, it's not like we see a log of it after the crash

But the arc cache should never cause an oom situation. It didn't use to when the old zfs implementation was in use

to be honest if it's proven not overprovisioning, I'd start suspecting the memory, and running memtest. I've seen weird crashes because of faulty memory, and it only surfaced when I started loading up on it

(of course, because it actually started storing data that got corrupteD)

Or you just try limiting the arc cache first ;-)

ya, as a first measure. and also adding cron jitter

or turning unnecessary shit completely off

I've never used cron jitter. Then again, my guests all use xfs or ext4

Turning unnecessary things off is good, but finding the root cause is even better :-)

the problem isn't zfs, but hammering the CPU at the same exact moment for no necessary reason. those jobs usually can run within a 30 second window

that's my case

You mean rowhammering the CPU?

nah, just overloading stuff unnecessarily. row hammering might also happen but I don't think because of cron :)

oh what, zuck is here.

was

karolyi: i was wondering if it could be a faulty memory. perhaps I should reboot the server and run memtest in bios

mary751: or a memtest usb stick/iso

mary751, <memtest.org> .

also, ventoy for booting it

Ventoy, or the brick of a CD-RW drive and a blank :-?