On Tue, Jul 12, 2016 at 10:12:36AM +0100, Daniel P. Berrange wrote:
Currently the QEMU processes inherit their core dump rlimit
from libvirtd, which is really suboptimal. This change allows
their limit to be directly controller from qemu.conf instead.
---
Changed in v2:
- Allow use of string "unlimited"
src/libvirt_private.syms | 2 ++
src/qemu/libvirtd_qemu.aug | 1 +
src/qemu/qemu.conf | 16 +++++++++++++++-
src/qemu/qemu_conf.c | 17 +++++++++++++++++
src/qemu/qemu_conf.h | 1 +
src/qemu/qemu_process.c | 1 +
src/qemu/test_libvirtd_qemu.aug.in | 1 +
src/util/vircommand.c | 14 ++++++++++++++
src/util/vircommand.h | 1 +
src/util/virprocess.c | 36 ++++++++++++++++++++++++++++++++++++
src/util/virprocess.h | 1 +
11 files changed, 90 insertions(+), 1 deletion(-)
[...]
diff --git a/src/qemu/libvirtd_qemu.aug b/src/qemu/libvirtd_qemu.aug
index 8bc23ba..a8edc2b 100644
--- a/src/qemu/libvirtd_qemu.aug
+++ b/src/qemu/libvirtd_qemu.aug
@@ -72,6 +72,7 @@ module Libvirtd_qemu =
| bool_entry "set_process_name"
| int_entry "max_processes"
| int_entry "max_files"
+ | int_entry "max_core"
This should be expanded to allow "unlimited" as well.
| str_entry "stdio_handler"
let device_entry = bool_entry "mac_filter"
[...]
diff --git a/src/qemu/qemu_conf.h b/src/qemu/qemu_conf.h
index 510cd9a..b730202 100644
--- a/src/qemu/qemu_conf.h
+++ b/src/qemu/qemu_conf.h
@@ -148,6 +148,7 @@ struct _virQEMUDriverConfig {
unsigned int maxProcesses;
unsigned int maxFiles;
+ unsigned long long maxCore;
This is not initialized anywhere, effectively making the limit default
to 0 IIUC.
[...]
diff --git a/src/util/virprocess.c b/src/util/virprocess.c
index 09dd3c9..2b71445 100644
--- a/src/util/virprocess.c
+++ b/src/util/virprocess.c
@@ -914,6 +914,42 @@ virProcessSetMaxFiles(pid_t pid ATTRIBUTE_UNUSED, unsigned int
files)
}
#endif /* ! (HAVE_SETRLIMIT && defined(RLIMIT_NOFILE)) */
+#if HAVE_SETRLIMIT && defined(RLIMIT_CORE)
+int
+virProcessSetMaxCoreSize(pid_t pid, unsigned long long bytes)
+{
+ struct rlimit rlim;
+
+ rlim.rlim_cur = rlim.rlim_max = bytes;
Shouldn't be this set to RLIM_INFINITY if "unlimited" was requested?
Not taht ULLONG_MAX would not be enough, it's just that it's rlim_t and
it would be nicer to use it as described.
Martin