On 20 September 2016 at 03:00, Thomas Daede wrote:
> For Fedora Workstation, the current limit on mlock()ed memory per user
> is 64kiB, which less than what some applications need.
>
> In particular, Bitcoin Core uses mlock() to prevent private keys from
> being swapped to disk. The total size of t
On Wednesday, 21 September 2016 at 18:05, Björn Persson wrote:
> Michael Catanzaro wrote:
> > Oh, GNOME keyring still works mostly fine, it just fails to lock the
> > memory to prevent it from being paged to disk. It only really matters
> > if you're running some ultra-secure military/government s
Michael Catanzaro wrote:
> Oh, GNOME keyring still works mostly fine, it just fails to lock the
> memory to prevent it from being paged to disk. It only really matters
> if you're running some ultra-secure military/government stuff, but it's
> not how it was designed to work.
Although I can't fin
On Wed, 2016-09-21 at 13:29 +0100, Richard W.M. Jones wrote:
> It also shouldn't be necessary to have to faff around with memory
> limits to do ordinary operations like starting a VM or trying to use
> GNOME keyring. The 64K limit is obviously much too low.
Oh, GNOME keyring still works mostly fi
On Wed, Sep 21, 2016 at 09:27:25AM +0200, Joachim Backes wrote:
> The command "ulimit -l ..." lets you control such a limit. See
> command ulimit -a:
I think everyone's well aware of that.
That doesn't help when we were trying to run ppc64 qemu instances,
since those were launched from libvirtd,
On 09/21/16 08:31, Sylvia wrote:
I think yes, that's the reason. Besides, I agree with Björn about
setting a 1% of the total memory.
The command "ulimit -l ..." lets you control such a limit. See command
ulimit -a:
core file size (blocks, -c) unlimited
data seg size (kby
I think yes, that's the reason. Besides, I agree with Björn about
setting a 1% of the total memory.
Cheers,
Sylvia
On Tue, 2016-09-20 at 09:40 -0500, Michael Catanzaro wrote:
> On Tue, 2016-09-20 at 00:00 -0700, Thomas Daede wrote:
> > For Fedora Workstation, the current limit on mlock()ed memo
On Tue, 2016-09-20 at 00:00 -0700, Thomas Daede wrote:
> For Fedora Workstation, the current limit on mlock()ed memory per
> user
> is 64kiB, which less than what some applications need.
Could this be why memory locking in seahorse/gnome-keyring has been
broken for years?
_
Thomas Daede wrote:
> The reason for the restriction is presumably an anti-DoS measure for
> multi-user systems. It's not really clear where the 64kiB value came
> from though - it seems like it could be much, much higher.
How about 1% of the total system memory? That would be tens of megabytes
p
Hello!
I think it's reasonable to raise the value, not sure how much, but
definitely should be higher.
Cheers,
Sylvia
On Tue, 2016-09-20 at 00:00 -0700, Thomas Daede wrote:
> > For Fedora Workstation, the current limit on mlock()ed memory per
user
> is 64kiB, which less than what some applica
For Fedora Workstation, the current limit on mlock()ed memory per user
is 64kiB, which less than what some applications need.
In particular, Bitcoin Core uses mlock() to prevent private keys from
being swapped to disk. The total size of the wallet keys can exceed 300kB.
Audio is another use case
11 matches
Mail list logo