FS#50019 - [docker] Could not run containers based on systemd with default config

Attached to Project: Community Packages
Opened by Mateusz Marzantowicz (mmarzantowicz) - Monday, 11 July 2016, 13:10 GMT
Last edited by Sébastien Luttringer (seblu) - Monday, 26 September 2016, 17:32 GMT
Task Type Bug Report
Category Packages
Status Closed
Assigned To Sébastien Luttringer (seblu)
Architecture x86_64
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description:
After recent updated, I'm no longer able to run containers managed by systemd (e.g. Fedora 24 with /usr/sbin/init as command to run). I get following result:

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 /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.


This might be caused by latest addition of libseccomp because on previous docker versions compiled without it, those containers work as expected.

Additional info:
* package version(s)
Name : docker
Version : 1:1.11.2-2


Steps to reproduce:

Run command:
$ docker run --rm -ti -e container=docker -v /sys/fs/cgroup:/sys/fs/cgroup:ro -v /run fedora:24 /usr/sbin/init
This task depends upon

Closed by  Sébastien Luttringer (seblu)
Monday, 26 September 2016, 17:32 GMT
Reason for closing:  Not a bug
Comment by Mateusz Marzantowicz (mmarzantowicz) - Tuesday, 12 July 2016, 10:23 GMT
Temporary workaround is to pass --security-opt seccomp=unconfined to docker run. This disables default seccomp policy, which allows systemd inside container to use required syscalls.
Comment by Sébastien Luttringer (seblu) - Sunday, 31 July 2016, 22:47 GMT
What are you suggesting as a long term solution?
1) We disable seccomp?
2) Change the default seccomp profiles to allow systemd required syscall?
Comment by Mateusz Marzantowicz (mmarzantowicz) - Monday, 01 August 2016, 22:03 GMT
Isn't it up to upstream project to provide long term solutions? Ideally, there would be a collection of seccomp profiles for various occasions (one for systemd based containers). What could be done in Arch package is loud notice about possible issues with seccomp and some containers. I think that seccomp should stay compiled in unless there is a policy in Arch that prevents partially broken solutions.
Comment by Sébastien Luttringer (seblu) - Friday, 19 August 2016, 00:11 GMT
So I let you discuss this upstream, and I we stay like that down here?
Comment by Mateusz Marzantowicz (mmarzantowicz) - Saturday, 27 August 2016, 11:48 GMT
OK, I'll try to discuss this with upstream and/or find/create some other solution. For now, I'm thinking about updating Arch Wiki to inform other users about this potential issue.

Loading...