我开始使用CoreOS（在AWS ECS上）。启动我的第一个容器后，我在journalctl中看到了这个：
Could not generate persistent MAC address for vethXXXX: No such file or directory
这里有更多背景信息。我已经删除了时间和实例信息，但这都在同一秒内。请注意，有两个不同的veth条目。我不知道这是否意味着什么。
systemd[1]: Started docker container 1234
systemd[1]: Starting docker container 1234
dockerd[595]: time="2015-07-23T23:30:52Z" level=info msg="GET /v1.17/containers/1234/json"
dockerd[595]: time="2015-07-23T23:30:52Z" level=info msg="+job container_inspect(1234)"
systemd-timesyncd[473]: Network configuration changed, trying to establish connection.systemd-udevd[7501]: Could not generate persistent MAC address for vethYYYY: No such file or directory
kernel: device vethXXXX entered promiscuous mode
kernel: IPv6: ADDRCONF(NETDEV_UP): vethXXXX: link is not ready
systemd-udevd[7508]: Could not generate persistent MAC address for vethXXXX: No such file or directory
systemd-networkd[497]: vethXXXX: Configured
kernel: eth0: renamed from vethYYYY
kernel: IPv6: ADDRCONF(NETDEV_CHANGE): vethXXXX: link becomes ready
kernel: docker0: port 2(vethXXXX) entered forwarding state
kernel: docker0: port 2(vethXXXX) entered forwarding state
systemd-networkd[497]: vethXXXX: Gained carrier
I found a discussion of this error on Ubuntu and it comes down to removing a udev rule，似乎并不存在于CoreOS上。 There's a discussion about iptables with OpenVPN，这似乎并不适用。 Here's a bridge rule for LXC on Ubuntu。再说一遍，我不知道如何应用它。
我还没有做过网络或法兰绒配置。如果问题出在该领域，我需要具体的步骤来解决它如何在AWS ECS中使用。
答案 0 :(得分：0)
我在使用系统化服务创建开发人员时遇到了类似的问题，然后我发现通过将服务类型更改为“ forking”（类型= forking）可以修复服务类型为“ simple”