Bug#917122: systemd can not start without name_to_handle_at option

Vladimir Tiukhtin v.tiukhtin at gmail.com
Sat Dec 22 23:29:52 GMT 2018


Package: systemd
Version: 232-25+deb9u6

Running Debian Stretch in docker container results in

Failed to determine whether /sys is a mount point: Operation not permitted
Failed to determine whether /proc is a mount point: Operation not permitted
Failed to determine whether /dev is a mount point: Operation not permitted
Failed to determine whether /dev/shm is a mount point: Operation not
permitted
Failed to determine whether /run is a mount point: Operation not permitted
Failed to determine whether /run/lock is a mount point: Operation not
permitted
Failed to determine whether /sys/fs/cgroup is a mount point: Operation not
permitted
Failed to determine whether /sys/fs/cgroup/systemd is a mount point:
Operation not permitted
[!!!!!!] Failed to mount API filesystems, freezing.
Freezing execution.

unless "name_to_handle_at" is whitelisted in default docker seccomp profile
which can be found here
https://github.com/moby/moby/blob/master/profiles/seccomp/default.json

Docker limits this system call be default. However RedHat image is running
correctly which means that they have back ported a patch for systemd from
upstream which resolves this problem on systemd side. Can you please do the
same?

The command I run
docker run -ti \
  --mount type=bind,source=/sys/fs/cgroup,target=/sys/fs/cgroup \
  --mount type=bind,source=/sys/fs/fuse,target=/sys/fs/fuse \
  --mount type=tmpfs,destination=/run \
  --mount type=tmpfs,destination=/run/lock \
  -e container=docker debian:stretch-slim

Vladimir
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/attachments/20181222/8f16e34d/attachment-0001.html>


More information about the Pkg-systemd-maintainers mailing list