[OE-core] [PATCH] systemd: decreasing default RLIMIT_NOFILE on qemu bsp

Alexander Kanavin alex.kanavin at gmail.com
Mon Aug 19 14:01:39 UTC 2019


Should the limit be simply raised? The 256M setup is crumbling on several
fronts (runtime tests, modernisation of X, various non-x86 qemu targets).
Adding per-image/target exceptions, custom non-upstreamable patches, or
sticking to deprecated configurations isn't the right thing to do, I think.

Alex

On Mon, 19 Aug 2019 at 15:34, Hongxu Jia <hongxu.jia at windriver.com> wrote:

> Since do_testimage for core-image-sato-sdk has memory limitation (256Mib)
> which caused rpc.statd failed with out of memory.
> [  531.306146] Out of memory: Kill process 193 (rpc.statd) score 200 or
> sacrifice child
>
> The rpc.statd allocates memory according to RLIMIT_NOFILE,
> so decrease it to 4k to keep sync with sysvinit
>
> After applying the patch, the memory cost is the same with sysvinit
> rpcuser    340  0.0  1.0   3212  2588 ?        Ss   13:20   0:00
> /usr/sbin/rpc.statd -F
> root       473  0.0  0.2   3464   496 ?        Ss   13:23   0:00
> /usr/sbin/rpc.mountd
>
> Signed-off-by: Hongxu Jia <hongxu.jia at windriver.com>
> ---
>  ...0001-decreasing-the-default-RLIMIT_NOFILE.patch | 35
> ++++++++++++++++++++++
>  meta/recipes-core/systemd/systemd_242.bb           |  4 +++
>  2 files changed, 39 insertions(+)
>  create mode 100644
> meta/recipes-core/systemd/systemd/0001-decreasing-the-default-RLIMIT_NOFILE.patch
>
> diff --git
> a/meta/recipes-core/systemd/systemd/0001-decreasing-the-default-RLIMIT_NOFILE.patch
> b/meta/recipes-core/systemd/systemd/0001-decreasing-the-default-RLIMIT_NOFILE.patch
> new file mode 100644
> index 0000000..fb8e2c9
> --- /dev/null
> +++
> b/meta/recipes-core/systemd/systemd/0001-decreasing-the-default-RLIMIT_NOFILE.patch
> @@ -0,0 +1,35 @@
> +From 55c7196163e481c508fa708b9b8f5e7bf2d2f007 Mon Sep 17 00:00:00 2001
> +From: Hongxu Jia <hongxu.jia at windriver.com>
> +Date: Mon, 19 Aug 2019 07:16:47 -0400
> +Subject: [PATCH] decreasing the default RLIMIT_NOFILE
> +
> +Since do_testimage for core-image-sato-sdk has memory limits (256Mib)
> +which caused rpc.statd failed with out of memory.
> +[  531.306146] Out of memory: Kill process 193 (rpc.statd) score 200 or
> sacrifice child
> +
> +The rpc.statd allocates memory according to RLIMIT_NOFILE,
> +so decrease it to 4k which keep sync with sysvinit
> +
> +Upstream-Status: Inappropriate [oe specific]
> +
> +Signed-off-by: Hongxu Jia <hongxu.jia at windriver.com>
> +---
> + meson.build | 2 +-
> + 1 file changed, 1 insertion(+), 1 deletion(-)
> +
> +diff --git a/meson.build b/meson.build
> +index 18a7cc5..e30894b 100644
> +--- a/meson.build
> ++++ b/meson.build
> +@@ -79,7 +79,7 @@ conf.set10('HAVE_SYSV_COMPAT', sysvinit_path != '' and
> sysvrcnd_path != '',
> +
> + conf.set10('BUMP_PROC_SYS_FS_FILE_MAX',
> get_option('bump-proc-sys-fs-file-max'))
> + conf.set10('BUMP_PROC_SYS_FS_NR_OPEN',
> get_option('bump-proc-sys-fs-nr-open'))
> +-conf.set('HIGH_RLIMIT_NOFILE',          512*1024)
> ++conf.set('HIGH_RLIMIT_NOFILE',          4*1024)
> +
> + # join_paths ignores the preceding arguments if an absolute component is
> + # encountered, so this should canonicalize various paths when they are
> +--
> +2.8.1
> +
> diff --git a/meta/recipes-core/systemd/systemd_242.bb
> b/meta/recipes-core/systemd/systemd_242.bb
> index 1953fef..ab15ad2 100644
> --- a/meta/recipes-core/systemd/systemd_242.bb
> +++ b/meta/recipes-core/systemd/systemd_242.bb
> @@ -58,6 +58,10 @@ SRC_URI_MUSL =
> "file://0001-Use-getenv-when-secure-versions-are-not-available.pa
>                 file://0001-do-not-disable-buffer-in-writing-files.patch \
>                 "
>
> +SRC_URI_append_qemuall = " \
> +               file://0001-decreasing-the-default-RLIMIT_NOFILE.patch \
> +"
> +
>  PAM_PLUGINS = " \
>      pam-plugin-unix \
>      pam-plugin-loginuid \
> --
> 2.8.1
>
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core at lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20190819/f1d37b34/attachment.html>


More information about the Openembedded-core mailing list