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