[systemd-devel] required free space for reloading

Alexander Dahl ada at thorsis.com
Wed Aug 25 08:13:59 UTC 2021


Hello everyone,

we use systemd on an embedded platform featuring the SAMA5D27C-D5M SoC [1], 
which has has 64 MiB of RAM.  The software is based on DistroKit [2] and 
ptxdist [3].  tmpfs are mounted through /etc/fstab and are allowed to take 20% 
of the memory, which I think is quite much already.

(The kernel itself reserves 17M for itself, with tmpfs mounted and only 
systemd (including dbus, udev, timesyncd) and NetworkManager running, there's 
less than 30M of free memory left for applications.)

We run into this on first boot:

    [   26.481404] systemd-rc-once[178]: Failed to reload daemon: Refusing to 
reexecute, not enough space available on /run/systemd. Currently, 9.2M are 
free, but a safety buffer of 16.0M is enforced.

I digged in systemd code and issues and found #5219 [4].  In the discussion it 
is stated the current requirement of 16 MiB of free memory in /run/systemd was 
chosen quite arbitrary, without serious investigation of actual demand?

I fully understand that requiring some amount of free memory is a solution to 
#5016 [5].  However the current limit does not seem to work well on systems 
with "low" memory like embedded systems.

I patched systemd and changed the limit to 8 MiB which works fine for our 
usecase.  Would such a patch have a chance to be accepted?  Or are regressions 
for #5016 to be expected on other systems?

What about trying to find a better solution than a rather high set fixed limit 
to be on the safe side?  Is there any way to determine or estimate the amount 
of memory needed for reloading in advance at runtime?

Thanks for reading
Greets
Alex

[1] https://www.microchip.com/en-us/product/ATSAMA5D27C-D5M
[2] https://www.pengutronix.de/en/software/distrokit.html
[3] https://www.ptxdist.org/
[4] https://github.com/systemd/systemd/pull/5219
[5] https://github.com/systemd/systemd/issues/5016





More information about the systemd-devel mailing list