[systemd-devel] hostnamectl doesn't work in a lxc container

Lennart Poettering lennart at poettering.net
Mon Feb 13 12:19:07 UTC 2017


On Sat, 11.02.17 13:03, Yuri Kanivetsky (yuri.kanivetsky at gmail.com) wrote:

> Hi,
> 
> Not sure it's a good place to ask. But it'd be great if you could help
> me with this one. Or at least tell me where to ask. I failed to find
> any systemd user mailing lists. The guys from lxc mailing list keep
> silence:
> 
> https://lists.linuxcontainers.org/pipermail/lxc-users/2017-February/012840.html
> 
> Failed at step NETWORK spawning /lib/systemd/systemd-hostnamed:
> Permission denied
> Feb 10 12:39:05 server1 systemd[1]: systemd-hostnamed.service: Main
> process exited, code=exited, status=225/NETWORK

> What's causing it? What can I check? How do I remedy this? Thanks in advance.

So, this is caused by PrivateNetwork=yes in the hostnamed unit
file. This is supposed to ensure that hostnamed runs within its own
network namespace, for sandboxing reasons. Depending on your precise
LXC configuration network namespaces are available to containers or
are not. If they aren't the above is what you are seeing.

That said, it's actually our intention to gracefully degrade if a
sandboxing option is set for a service and we lack the privs to set it
up. That's OK since sandboxing while enhancing security lockdown
doesn't actually provide anything the service would need to run
correctly.

If you look into the TODO file in our git tree, you'll find this item:

* fix PrivateNetwork= so that we fall back gracefully on kernels
  lacking namespacing support (similar for the other namespacing
  options)

Until that#s fixed you'll see the problem in your setup.

A local work-around would be to either grant your LXC container enough
privs to do network namespacing internally. Or simply disable the
option in hostnamed, by placing a drop-in file that turns it off...

Lennart

-- 
Lennart Poettering, Red Hat


More information about the systemd-devel mailing list