When runc is started as a `Type=notify` systemd service,
runc opens up its own listening socket inside the container
to act as a proxy between the container and systemd for passing
notify messages.
The domain socket that runc creates is only writeable by the user
running runc however, so if the container has a different UID/GID
then nothing inside the container will be able to write to the socket.
The fix is to change the permissions of the notify listener socket to 0777.
Signed-off-by: Joe Burianek <joe.burianek@pantheon.io>
Updated logrus to use v1 which includes a breaking name change Sirupsen -> sirupsen.
This includes a manual edit of the docker term package to also correct the name there too.
Signed-off-by: Steven Hartland <steven.hartland@multiplay.co.uk>
The current support of systemd-notify has a race condition as the
message send to the systemd notify socket might be dropped if the sender
process is not running by the time systemd checks for the sender of the
datagram. A proper fix of this in systemd would require changes to the
kernel to maintain the cgroup of the sender process when it is dead (but
it is not probably going to happen...)
Generally, the solution to this issue is to specify the PID in the
message itself so that systemd has not to guess the sender, but this
wouldn't work when running in a PID namespace as the container will pass
the PID known in its namespace (something like PID=1,2,3..) and systemd
running on the host is not able to map it to the runc service.
The proposed solution is to have a proxy in runc that forwards the
messages to the host systemd.
Example of this issue:
https://github.com/projectatomic/atomic-system-containers/pull/24
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
Joe Burianek
Dominik Süß
W. Trevor King
Steven Hartland
Giuseppe Scrivano