Date: Thu, 17 Oct 2019 15:05:32 +0200 From: Andrea Venturoli <ml@netfence.it> To: MJ <mafsys1234@gmail.com>, freebsd-questions@freebsd.org, kpn@neutralgood.org Subject: Re: Avoiding LibreOffice DOS Message-ID: <62d45c64-ac95-43a7-5e39-9a94d26d323c@netfence.it> In-Reply-To: <be6c4b7f-0a91-8795-3218-65e933c6649d@gmail.com> References: <eee23781-9264-3de5-1a27-3879e731a5fc@netfence.it> <be6c4b7f-0a91-8795-3218-65e933c6649d@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?62d45c64-ac95-43a7-5e39-9a94d26d323c>