[systemd-devel] PrivateNetwork=yes is memory costly

[Christopher Wong]

Hi Lennart,


It is definitely a functionality we want to use. However, the memory came as an unexpected side effect. Since we are not only enabling this for one single service, instead we are applying it globally for all services.


Now due to this huge memory consumption we are trying to put everything into the same namespace using JoinsNamespaceOf=<some-service>. It seems to consume less memory.


Best Regards,

Christopher Wong
________________________________
From: Lennart Poettering <lennart at poettering.net>
Sent: Wednesday, March 9, 2022 4:18:22 PM
To: Christopher Wong
Cc: systemd-devel at lists.freedesktop.org
Subject: Re: [systemd-devel] PrivateNetwork=yes is memory costly

On Mo, 07.03.22 15:10, Christopher Wong (Christopher.Wong at axis.com) wrote:

> Hi,
>
>
> It seems that PrivateNetwork=yes is a memory consuming
> directive. The kernel seems to allocate quite an amount of memory
> for each service (~50 kB) that has this directive enabled. I wonder
> if this is expected and if anyone has had similar experience?

PrivateNetwork=yes means that a private network namespace is allocated
for the service. If you think network namespaces are too expensive in
their current implementation, please bring this up with the kernel
people, because they are a kernel concept after all, we just allocate
them if told so.

network namespaces are an effective way to disconnect a service from
the network, if the service doesn't need it. It's probably one of the
most relevant sandboxing options we offer, since disabling the attack
surface called "network" for a service is of such major
importance. That said, if you disable the network namespace
functionality in the kernel systemd will handle this gracefully, and
not use it. If the feature is available in the kernel we will however
use it.

> Is there any ways to reduce the usage?

Besides turning it off? Nothing I was aware of.

Lennart

--
Lennart Poettering, Berlin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20220310/02a945a7/attachment.htm>