Avoiding LibreOffice DOS

Andrea Venturoli ml at netfence.it
Thu Oct 17 13:05:40 UTC 2019


On 2019-10-17 13:48, MJ wrote:

> Well the short answer is: You pretty well can't.

:-O



> If LibreOffice gets in such a tight loop processing that the kernel 
> can't process keyboard commands, then you've got no alternative.

I thought root could always stop a user process!
I wasn't logged in as root at the time, but I'll previously log in (in a 
VT or via SSH) next time and see if this helps.



>Unless you can wait for it to stop, if it will ever stop.

It won't stop (at least in about an hour, which is too much to wait anyhow).



> Mucking around with settings is a waste of time until you know what's 
> causing the lock-up. Is it the cpu? Memory exhaustion? etc

 From the bars in my XFCE panel I don't think it's the CPU (BTW, this is 
a 4-core system).
As I said, I think it's a problem with memory.

In the past I've seen several "Process X was killed due to out of swap 
space" messages (or the like, I don't have them in sight now); why 
doesn't it happen in this case?



> Running it virtually would seem the only quick practical approach

I thought about this, but putting a virtual machine up would be a lot of 
work; besides, I'd like to understand and solve the problem at its root.
Today it's LibreOffice; tomorrow who knows...



> better still fix your program. :-)

That's what I'm trying to do... but it's hard if I need to constantly 
reboot/fsck/etc... :-)





On 2019-10-17 14:08, Kevin P. Neal wrote:
> A shell script wrapper around LibreOffice to lower the ulimit just for
> LibreOffice?

This might be interesting.
Unfortunately, "man ulimit" is useless and the handbook doesn't talk 
about this.
I tried to gather info from a web search, but I'm still not completely sure.

After I set vmemoryuse in /etc/login.conf, running "ulimit -a" shows:
cpu time               (seconds, -t)  unlimited
file size           (512-blocks, -f)  unlimited
data seg size           (kbytes, -d)  33554432
stack size              (kbytes, -s)  524288
core file size      (512-blocks, -c)  unlimited
max memory size         (kbytes, -m)  unlimited
locked memory           (kbytes, -l)  64
max user processes              (-u)  12200
open files                      (-n)  235440
virtual mem size        (kbytes, -v)  6291456
swap limit              (kbytes, -w)  unlimited
socket buffer size       (bytes, -b)  unlimited
pseudo-terminals                (-p)  unlimited
kqueues                         (-k)  unlimited
umtx shared locks               (-o)  unlimited

So I think I was able to limit virtual memory for all the processes of 
my user to 6GiB, but this obviously didn't help.

If I issue "ulimit -v 2097152" and "ulimit -a" again, I still see the 
same values as above.
So either "ulimit -v 2097152" did nothing or I'm not understanding it 
correctly...


Once I solve the above, should I use -m instead of -v (or the 
corresponding memoryuse insetead of vmemoryuse in /etc/login.conf)?

  bye & Thanks
	av.


More information about the freebsd-questions mailing list