> > Always surprises me when people are willing to run things like that as > root..
This is a single purpose system so I'm not worried about collateral damage, although I agree it's best practice to use a limited account for usrland applications. I had thought it would be experimentally easier to try this using root. Did you logout and back in between updating login.conf and retrying? > (Needs to be a full logout; if you use an ssh persistent connection that > will need to be closed; if you use X that needs to be restarted). > Check what ulimit -a says. > Yes, I tried a full logoug and also running "cap_mkdb /etc/login.conf" after updating. > LONG in the cpu capabilities line means that the hardware can usually run > amd64. That would give you a few hundred MB more physical memory, and much > more available memory address space (and a lot of software is only really > tested on 64-bit archs these days anyway..) So you might possibly like > to try that. > Thanks, I overlooked this and thought it was a 32bit machine. After installing amd64 and running bitcoind under a limited user account, It's been working perfectly out of the box without any system modifications. Cheers, -Yancy On Sat, May 8, 2021 at 12:29 PM Stuart Henderson <s...@spacehopper.org> wrote: > On 2021-05-07, yancy ribbens <yancy.ribb...@gmail.com> wrote: > > I'm running 6.8 and trying to run bitcoind (C++), however, I continue to > > receive a core dump while running the application (out of memory). The > > dmesg file is below. > > Always surprises me when people are willing to run things like that as > root.. > > > The application is running as root and I've set datasize-max and > > datasize-cur to infinity in the login.conf daemon section as I suspect > the > > core dump is happening because of an upper memory bound enforced by the > OS. > > Did you logout and back in between updating login.conf and retrying? > (Needs to be a full logout; if you use an ssh persistent connection that > will need to be closed; if you use X that needs to be restarted). > Check what ulimit -a says. > > > running the application \time -l twice shows the resident set size each > > time to be: > > 662128 > > 650388 > > > > I've also observed "top" while running and there is more than 1GB free > and > > SWAP is not being used at the time it core dumps (out of memory). > > If it requests an allocation which fails, that memory won't be "used" to > show up in top / time -l. > > > Is this a problem with a login.conf parameter or something else? > > > > OpenBSD 6.8 (GENERIC.MP) #440: Sun Oct 4 18:33:20 MDT 2020 > > dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP > ... > > cpu0: > > > FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,NXE,LONG,LAHF,PERF,SENSOR,MELTDOWN > > LONG in the cpu capabilities line means that the hardware can usually run > amd64. That would give you a few hundred MB more physical memory, and much > more available memory address space (and a lot of software is only really > tested on 64-bit archs these days anyway..) So you might possibly like > to try that. > > >
