geli(8) breaks after a couple hours of uptime

Ulrich Spörlein uqs at
Fri Feb 8 11:48:29 UTC 2013

On Fri, 2013-02-08 at 09:57:09 +0100, Fabian Keil wrote:
> Ulrich Spörlein <uqs at> wrote:
> > On Thu, 2013-02-07 at 15:33:22 +0100, Fabian Keil wrote:
> > > Ulrich Spörlein <uqs at> wrote:
> > > 
> > > > Yes, it's pretty much as weird as it sounds. All new machine, forklifted
> > > > the image from on old i386 machine running 8.x to current on amd64.
> > > > 
> > > > Everything seemingly works fine, attaching geli volumes shortly after
> > > > boot is fine, attached devices continue to work fine. There are no
> > > > strange crashes with this machine or anything, but when I try to attach
> > > > an USB volume the next day, geli attach segfaults.
> > > 
> > > This could be:
> > >
> > Except it happens to me when run as root, and:
> Depending on your settings the limit could still apply.
> Did you check with ulimit -l to be sure?
> > root at coyote:~# sysctl vm.old_mlock
> > vm.old_mlock: 0
> Looks like I got the logic wrong in the PR ...
> fk at r500 ~ $sysctl -d vm.old_mlock
> vm.old_mlock: Do not apply RLIMIT_MEMLOCK on mlockall
> Fabian

Of course!
root at coyote:~# ulimit -l

The problem here is that I login via my user account, then either use
sudo or sudo -i for a root shell, this however does not raise the
memorylocked limit. So when I said this works during boot and shortly
after, it's because I haven't started my screen session yet, through
which I do all the work, usually, but have logged in with a direct root
shell. D'oh!

It looks like 128k as a limit is still too low for geli(8) to work, and
I've set it to 256k now, so that I can use "sudo geli". Can you maybe
revise the patch to not use 1024k as an arbitrary limit, but rather make
sure you test for precisely as much memory as will be needed?

Also, can we maybe revisit the new 64k default limit, as it will
obviously make peoples work with geli a bit painful, this should work
out of the box.


More information about the freebsd-current mailing list