On Sat May 16, 2026 at 3:21 PM EDT, H. Hartzer wrote: > I wanted to say that as of v0.18.5.0, Monero is running a lot better on > OpenBSD. I still have to use --db-sync-mode=fast:async:10000 -- if I > don't, once synced the system is incredibly slow. > > I wanted to say this in case anyone had given Monero a try under OpenBSD > before and found it unusable. It's still not *good*, but it's getting > better and maybe worth a second chance. > > Stopping the daemon does hang the system for about a minute, which is a > lot better than it used to be! > > On Wed Dec 17, 2025 at 10:03 AM UTC, Stuart Henderson wrote: >> as said before... >> >> https://marc.info/?l=openbsd-ports&m=176200894330926&w=2 >> >> without patching to force writemap, lmdb is *not* going to work on OpenBSD > > I still haven't looked into this yet. While I'd also love to see Monero in the OpenBSD ports tree I still unfortunately am of the mind that it's still too broken to consider. The fact that the database can only run in the unsafe mode where any unexpected stops can irrecoverably corrupt the entire database is pretty horrid to the end-user.
As noted, The reason this issue occurs is because OpenBSD--unlike FreeBSD and Linux--lacks a Unified Buffer Cache (ubc). A ubc makes it so when a program writes to a file using write(), the OS modifies the same physical memory pages used by mmap. While neither a kernel, Monero, or LMDB dev, from the research I've done I've pieced together that there are really only two real solutions to run Monero "smoothly" on OpenBSD, both of which are not easy: 1. Like Linux/FreeBSD do, the OpenBSD kernel would need a ubc. 2. LMDB would need to be vendored to bridge the split-cache gap manually without relying on the OS. Every time a write() call is made, LMDB would need to issue an msync(MS_INVALIDATE) on the exact memory pages that were modified (though this may just introduce the exact same halting overhead). Andrew
