SELinux: container exits with code 139

kind bug
Description
podman run busybox echo hello world returns exit code 139. 139 is not part of the listed exit codes in https://github.com/projectatomic/libpod/blob/master/docs/podman-run.1.md
Steps to reproduce the issue:
I'm provisioning a Vagrant Box using the vagrantfile
Vagrant.configure('2') do |config|
  config.vm.box = "fedora/27-cloud-base"

  # Docker
  config.vm.provision :docker

  # Install appc tools & rocket
  config.vm.provision :shell,inline: <<EOF

EOF
end

> vagrant ssh
Last login: Thu Jul 19 20:49:03 2018 from <IP_ADDRESS>
[vagrant@localhost ~]$ sudo -s
[root@localhost vagrant]# podman run busybox echo hello world
[root@localhost vagrant]# echo $?
139

Output of podman version:
podman version 0.7.1

Output of podman info:
host:
  MemFree: 85467136
  MemTotal: 509480960
  SwapFree: 0
  SwapTotal: 0
  arch: amd64
  cpus: 1
  hostname: localhost.localdomain
  kernel: 4.13.9-300.fc27.x86_64
  os: linux
  uptime: 13m 1.36s
insecure registries:
  registries: []
registries:
  registries:
  - docker.io
  - registry.fedoraproject.org
  - registry.access.redhat.com
store:
  ContainerStore:
    number: 2
  GraphDriverName: overlay
  GraphOptions:
  - overlay.override_kernel_check=true
  GraphRoot: /var/lib/containers/storage
  GraphStatus:
    Backing Filesystem: extfs
    Native Overlay Diff: "true"
    Supports d_type: "true"
  ImageStore:
    number: 1
  RunRoot: /var/run/containers/storage```

**Additional environment details (AWS, VirtualBox, physical, etc.):**

see Vagrantfile above

Error 139 with no output? Interesting.
Can you add a --log-level=debug between podman and run to get debug-level logs and try and see what's going wrong?

That is the exit code from the echo command I believe. I am not seeing anything going wrong there?

@rhatdan why should the echo command error out? I would have expected to just print hello world
@mheon this is the debug output
[root@localhost vagrant]# podman --log-level=debug run busybox echo hello world
DEBU[0000] [graphdriver] trying provided driver "overlay"
DEBU[0000] overlay: override_kernelcheck=true
DEBU[0000] overlay test mount with multiple lowers succeeded
DEBU[0000] backingFs=extfs, projectQuotaSupported=false, useNativeDiff=true
INFO[0000] CNI network podman (type=bridge) is used from /etc/cni/net.d/87-podman-bridge.conflist
INFO[0000] Initial CNI setting succeeded
DEBU[0000] parsed reference into "[overlay@/var/lib/containers/storage+/var/run/containers/storage:overlay.override_kernel_check=true]docker.io/library/busybox:latest"
DEBU[0000] parsed reference into "[overlay@/var/lib/containers/storage+/var/run/containers/storage:overlay.override_kernel_check=true]@22c2dd5ee85dc01136051800684b0bf30016a3082f97093c806152bf43d4e089"
DEBU[0000] exporting opaque data as blob "sha256:22c2dd5ee85dc01136051800684b0bf30016a3082f97093c806152bf43d4e089"
DEBU[0000] parsed reference into "[overlay@/var/lib/containers/storage+/var/run/containers/storage:overlay.override_kernel_check=true]@22c2dd5ee85dc01136051800684b0bf30016a3082f97093c806152bf43d4e089"
DEBU[0000] exporting opaque data as blob "sha256:22c2dd5ee85dc01136051800684b0bf30016a3082f97093c806152bf43d4e089"
DEBU[0000] parsed reference into "[overlay@/var/lib/containers/storage+/var/run/containers/storage:overlay.override_kernel_check=true]@22c2dd5ee85dc01136051800684b0bf30016a3082f97093c806152bf43d4e089"
DEBU[0000] Using bridge netmode
DEBU[0000] parsed reference into "[overlay@/var/lib/containers/storage+/var/run/containers/storage:overlay.override_kernel_check=true]@22c2dd5ee85dc01136051800684b0bf30016a3082f97093c806152bf43d4e089"
DEBU[0000] exporting opaque data as blob "sha256:22c2dd5ee85dc01136051800684b0bf30016a3082f97093c806152bf43d4e089"
DEBU[0000] created container "fa48e310b2df07a296fd1b6f6725922f9ff15a52b6ceee8b136ced44be16943c"
DEBU[0000] container "fa48e310b2df07a296fd1b6f6725922f9ff15a52b6ceee8b136ced44be16943c" has work directory "/var/lib/containers/storage/overlay-containers/fa48e310b2df07a296fd1b6f6725922f9ff15a52b6ceee8b136ced44be16943c/userdata"
DEBU[0000] container "fa48e310b2df07a296fd1b6f6725922f9ff15a52b6ceee8b136ced44be16943c" has run directory "/var/run/containers/storage/overlay-containers/fa48e310b2df07a296fd1b6f6725922f9ff15a52b6ceee8b136ced44be16943c/userdata"
DEBU[0000] New container created "fa48e310b2df07a296fd1b6f6725922f9ff15a52b6ceee8b136ced44be16943c"
DEBU[0000] container "fa48e310b2df07a296fd1b6f6725922f9ff15a52b6ceee8b136ced44be16943c" has CgroupParent "/libpod_parent/libpod-fa48e310b2df07a296fd1b6f6725922f9ff15a52b6ceee8b136ced44be16943c"
DEBU[0000] Not attaching to stdin
DEBU[0000] mounted container "fa48e310b2df07a296fd1b6f6725922f9ff15a52b6ceee8b136ced44be16943c" at "/var/lib/containers/storage/overlay/01b815e3799209624f545845955c5c43a5eab6e9943ae99233626eb5ec837812/merged"
DEBU[0000] Created root filesystem for container fa48e310b2df07a296fd1b6f6725922f9ff15a52b6ceee8b136ced44be16943c at /var/lib/containers/storage/overlay/01b815e3799209624f545845955c5c43a5eab6e9943ae99233626eb5ec837812/merged
DEBU[0000] Made network namespace at /var/run/netns/cni-b47310e9-54e6-f42f-9b5c-2094af0907a0 for container fa48e310b2df07a296fd1b6f6725922f9ff15a52b6ceee8b136ced44be16943c
INFO[0000] Got pod network {Name:eager_wozniak Namespace:eager_wozniak ID:fa48e310b2df07a296fd1b6f6725922f9ff15a52b6ceee8b136ced44be16943c NetNS:/var/run/netns/cni-b47310e9-54e6-f42f-9b5c-2094af0907a0 PortMappings:[]}
INFO[0000] About to add CNI network cni-loopback (type=loopback)
INFO[0000] Got pod network {Name:eager_wozniak Namespace:eager_wozniak ID:fa48e310b2df07a296fd1b6f6725922f9ff15a52b6ceee8b136ced44be16943c NetNS:/var/run/netns/cni-b47310e9-54e6-f42f-9b5c-2094af0907a0 PortMappings:[]}
INFO[0000] About to add CNI network podman (type=bridge)
DEBU[0000] Response from CNI plugins: Interfaces:[{Name:cni0 Mac:0a:58:0a:58:00:01 Sandbox:} {Name:veth2676f778 Mac:ee:6a:bc:32:22:f4 Sandbox:} {Name:eth0 Mac:0a:58:0a:58:00:08 Sandbox:/var/run/netns/cni-b47310e9-54e6-f42f-9b5c-2094af0907a0}], IP:[{Version:4 Interface:0xc4204023e8 Address:{IP:<IP_ADDRESS> Mask:ffff0000} Gateway:<IP_ADDRESS>}], Routes:[{Dst:{IP:<IP_ADDRESS> Mask:00000000} GW:<nil>}], DNS:{Nameservers:[] Domain: Search:[] Options:[]}
DEBU[0000] Running iptables command: -t filter -I FORWARD -s <IP_ADDRESS> ! -o <IP_ADDRESS> -j ACCEPT
DEBU[0000] file "/etc/containers/mounts.conf" not found, skipping...
DEBU[0000] /etc/system-fips does not exist on host, not mounting FIPS mode secret
WARN[0000] failed to parse language "en_US.UTF-8": language: tag is not well-formed
DEBU[0000] reading hooks from /usr/share/containers/oci/hooks.d
DEBU[0000] added hook /usr/share/containers/oci/hooks.d/oci-systemd-hook.json
DEBU[0000] added hook /usr/share/containers/oci/hooks.d/oci-umount.json
DEBU[0000] hook oci-systemd-hook.json did not match
DEBU[0000] hook oci-umount.json did not match
DEBU[0000] parsed reference into "[overlay@/var/lib/containers/storage+/var/run/containers/storage:overlay.override_kernel_check=true]@22c2dd5ee85dc01136051800684b0bf30016a3082f97093c806152bf43d4e089"
DEBU[0000] parsed reference into "[overlay@/var/lib/containers/storage+/var/run/containers/storage:overlay.override_kernel_check=true]@22c2dd5ee85dc01136051800684b0bf30016a3082f97093c806152bf43d4e089"
DEBU[0000] exporting opaque data as blob "sha256:22c2dd5ee85dc01136051800684b0bf30016a3082f97093c806152bf43d4e089"
DEBU[0000] parsed reference into "[overlay@/var/lib/containers/storage+/var/run/containers/storage:overlay.override_kernel_check=true]@22c2dd5ee85dc01136051800684b0bf30016a3082f97093c806152bf43d4e089"
DEBU[0000] exporting opaque data as blob "sha256:22c2dd5ee85dc01136051800684b0bf30016a3082f97093c806152bf43d4e089"
DEBU[0000] parsed reference into "[overlay@/var/lib/containers/storage+/var/run/containers/storage:overlay.override_kernel_check=true]@22c2dd5ee85dc01136051800684b0bf30016a3082f97093c806152bf43d4e089"
DEBU[0000] Setting CGroup path for container fa48e310b2df07a296fd1b6f6725922f9ff15a52b6ceee8b136ced44be16943c to /libpod_parent/libpod-fa48e310b2df07a296fd1b6f6725922f9ff15a52b6ceee8b136ced44be16943c
DEBU[0000] Created OCI spec for container fa48e310b2df07a296fd1b6f6725922f9ff15a52b6ceee8b136ced44be16943c at /var/lib/containers/storage/overlay-containers/fa48e310b2df07a296fd1b6f6725922f9ff15a52b6ceee8b136ced44be16943c/userdata/config.json
DEBU[0000] %s messages will be logged to syslog/usr/libexec/podman/conmon
DEBU[0000] running conmon: /usr/libexec/podman/conmon    args=[-c fa48e310b2df07a296fd1b6f6725922f9ff15a52b6ceee8b136ced44be16943c -u fa48e310b2df07a296fd1b6f6725922f9ff15a52b6ceee8b136ced44be16943c -r /usr/bin/runc -b /var/lib/containers/storage/overlay-containers/fa48e310b2df07a296fd1b6f6725922f9ff15a52b6ceee8b136ced44be16943c/userdata -p /var/run/containers/storage/overlay-containers/fa48e310b2df07a296fd1b6f6725922f9ff15a52b6ceee8b136ced44be16943c/userdata/pidfile -l /var/lib/containers/storage/overlay-containers/fa48e310b2df07a296fd1b6f6725922f9ff15a52b6ceee8b136ced44be16943c/userdata/ctr.log --exit-dir /var/run/libpod/exits --socket-dir-path /var/run/libpod/socket --syslog]
option parsing failed: Unknown option --syslog
DEBU[0000] Cleaning up container fa48e310b2df07a296fd1b6f6725922f9ff15a52b6ceee8b136ced44be16943c
DEBU[0000] Running iptables command: -t filter -D FORWARD -s <IP_ADDRESS> ! -o <IP_ADDRESS> -j ACCEPT
DEBU[0000] Tearing down network namespace at /var/run/netns/cni-b47310e9-54e6-f42f-9b5c-2094af0907a0 for container fa48e310b2df07a296fd1b6f6725922f9ff15a52b6ceee8b136ced44be16943c
INFO[0000] Got pod network {Name:eager_wozniak Namespace:eager_wozniak ID:fa48e310b2df07a296fd1b6f6725922f9ff15a52b6ceee8b136ced44be16943c NetNS:/var/run/netns/cni-b47310e9-54e6-f42f-9b5c-2094af0907a0 PortMappings:[]}
INFO[0000] About to del CNI network podman (type=bridge)
DEBU[0000] unmounted container "fa48e310b2df07a296fd1b6f6725922f9ff15a52b6ceee8b136ced44be16943c"
ERRO[0000] exit status 1

still the same message
DEBU[0000] running conmon: /usr/libexec/podman/conmon    args=[-c 2b71a3625bcb8bd3800fde5aba4f136f518d3575985e5e47766e1be26613d783 -u 2b71a3625bcb8bd3800fde5aba4f136f518d3575985e5e47766e1be26613d783 -r /usr/bin/runc -b /var/lib/containers/storage/overlay-containers/2b71a3625bcb8bd3800fde5aba4f136f518d3575985e5e47766e1be26613d783/userdata -p /var/run/containers/storage/overlay-containers/2b71a3625bcb8bd3800fde5aba4f136f518d3575985e5e47766e1be26613d783/userdata/pidfile -l /var/lib/containers/storage/overlay-containers/2b71a3625bcb8bd3800fde5aba4f136f518d3575985e5e47766e1be26613d783/userdata/ctr.log --exit-dir /var/run/libpod/exits --socket-dir-path /var/run/libpod/socket --syslog]
option parsing failed: Unknown option --syslog

[root@localhost vagrant]#  /usr/libexec/podman/conmon --version
conmon version 1.11.0-dev
commit: 6a5c1201d97605ab3a0d0f80b5c814e4205ef484

/usr/libexec/podman/conmon --help

no, it doesn't
[root@localhost vagrant]# /usr/libexec/podman/conmon --help
Usage:
  conmon [OPTION?] - conmon utility

Help Options:
  -h, --help                  Show help options

Application Options:
  -t, --terminal              Terminal
  -i, --stdin                 Stdin
  --leave-stdin-open          Leave stdin open when attached client disconnects
  -c, --cid                   Container ID
  -u, --cuuid                 Container UUID
  -r, --runtime               Runtime path
  --restore                   Restore a container from a checkpoint
  --no-new-keyring            Do not create a new session keyring for the container
  --no-pivot                  Do not use pivot_root
  --replace-listen-pid        Replace listen pid if set for oci-runtime pid
  -b, --bundle                Bundle path
  --pidfile                   PID file (DEPRECATED)
  -p, --container-pidfile     Container PID file
  -P, --conmon-pidfile        Conmon daemon PID file
  -s, --systemd-cgroup        Enable systemd cgroup manager
  -e, --exec                  Exec a command in a running container
  --exec-process-spec         Path to the process spec for exec
  --exit-dir                  Path to the directory where exit files are written
  --exit-command              Path to the program to execute when the container terminates its execution
  --exit-command-arg          Additional arg to pass to the exit command.  Can be specified multiple times
  -l, --log-path              Log file path
  -T, --timeout               Timeout in seconds
  --log-size-max              Maximum size of log file
  --socket-dir-path           Location of container attach sockets
  --version

It's running the packaged conmon, it just seems to be too old.
@rhatdan Looks like a packaging issue on F27

This also isn't our root cause, --syslog isn't added to the conmon command line unless --log-level=debug is present - we don't use the extra logging otherwise

Yes I screwed up on podman for f27.  Building now.  I will pull the PR.
Thanks @lukasheinrich for finding this.

https://koji.fedoraproject.org/koji/taskinfo?taskID=28453605

Should be fixed in podman-0.7.2-2.git4ca4c5f.fc27

We really need to add a check for bad Conmon versions. We got the --version flag merged there, but we haven't been keeping it updated, so we can't reliably check it to see if it's a good version.

Just moved to batch update
dnf install -y podman --enablerepo=updates-testing

the syslog thing seems solved, but still it's not working
[root@localhost vagrant]# podman --log-level=debug run --rm -it busybox echo ok
DEBU[0000] [graphdriver] trying provided driver "overlay"
DEBU[0000] overlay: override_kernelcheck=true
DEBU[0000] overlay test mount with multiple lowers succeeded
DEBU[0000] backingFs=extfs, projectQuotaSupported=false, useNativeDiff=true
INFO[0000] Found CNI network podman (type=bridge) at /etc/cni/net.d/87-podman-bridge.conflist
DEBU[0000] parsed reference into "[overlay@/var/lib/containers/storage+/var/run/containers/storage:overlay.override_kernel_check=true]docker.io/library/busybox:latest"
DEBU[0000] parsed reference into "[overlay@/var/lib/containers/storage+/var/run/containers/storage:overlay.override_kernel_check=true]@22c2dd5ee85dc01136051800684b0bf30016a3082f97093c806152bf43d4e089"
DEBU[0000] exporting opaque data as blob "sha256:22c2dd5ee85dc01136051800684b0bf30016a3082f97093c806152bf43d4e089"
DEBU[0000] parsed reference into "[overlay@/var/lib/containers/storage+/var/run/containers/storage:overlay.override_kernel_check=true]@22c2dd5ee85dc01136051800684b0bf30016a3082f97093c806152bf43d4e089"
DEBU[0000] exporting opaque data as blob "sha256:22c2dd5ee85dc01136051800684b0bf30016a3082f97093c806152bf43d4e089"
DEBU[0000] parsed reference into "[overlay@/var/lib/containers/storage+/var/run/containers/storage:overlay.override_kernel_check=true]@22c2dd5ee85dc01136051800684b0bf30016a3082f97093c806152bf43d4e089"
DEBU[0000] AppArmor is not supported: setting empty profile
DEBU[0000] Using bridge netmode
DEBU[0000] parsed reference into "[overlay@/var/lib/containers/storage+/var/run/containers/storage:overlay.override_kernel_check=true]@22c2dd5ee85dc01136051800684b0bf30016a3082f97093c806152bf43d4e089"
DEBU[0000] exporting opaque data as blob "sha256:22c2dd5ee85dc01136051800684b0bf30016a3082f97093c806152bf43d4e089"
DEBU[0000] created container "74a2479af78c4348e8de40e7cfae9fb68939682a52bce2d36246ece091527961"
DEBU[0000] container "74a2479af78c4348e8de40e7cfae9fb68939682a52bce2d36246ece091527961" has work directory "/var/lib/containers/storage/overlay-containers/74a2479af78c4348e8de40e7cfae9fb68939682a52bce2d36246ece091527961/userdata"
DEBU[0000] container "74a2479af78c4348e8de40e7cfae9fb68939682a52bce2d36246ece091527961" has run directory "/var/run/containers/storage/overlay-containers/74a2479af78c4348e8de40e7cfae9fb68939682a52bce2d36246ece091527961/userdata"
DEBU[0000] New container created "74a2479af78c4348e8de40e7cfae9fb68939682a52bce2d36246ece091527961"
DEBU[0000] container "74a2479af78c4348e8de40e7cfae9fb68939682a52bce2d36246ece091527961" has CgroupParent "/libpod_parent/libpod-74a2479af78c4348e8de40e7cfae9fb68939682a52bce2d36246ece091527961"
DEBU[0000] Handling terminal attach
DEBU[0000] mounted container "74a2479af78c4348e8de40e7cfae9fb68939682a52bce2d36246ece091527961" at "/var/lib/containers/storage/overlay/aa60a1ee147fb9f30010fff55ebea7e4ec2237aa4768654b52684dc3b9881885/merged"
DEBU[0000] Created root filesystem for container 74a2479af78c4348e8de40e7cfae9fb68939682a52bce2d36246ece091527961 at /var/lib/containers/storage/overlay/aa60a1ee147fb9f30010fff55ebea7e4ec2237aa4768654b52684dc3b9881885/merged
DEBU[0000] Made network namespace at /var/run/netns/cni-bd5d4ce5-d2e8-9869-6cc2-ce1034b5c63d for container 74a2479af78c4348e8de40e7cfae9fb68939682a52bce2d36246ece091527961
INFO[0000] Got pod network &{Name:upbeat_jepsen Namespace:upbeat_jepsen ID:74a2479af78c4348e8de40e7cfae9fb68939682a52bce2d36246ece091527961 NetNS:/var/run/netns/cni-bd5d4ce5-d2e8-9869-6cc2-ce1034b5c63d PortMappings:[] Networks:[]}
INFO[0000] About to add CNI network cni-loopback (type=loopback)
INFO[0000] Got pod network &{Name:upbeat_jepsen Namespace:upbeat_jepsen ID:74a2479af78c4348e8de40e7cfae9fb68939682a52bce2d36246ece091527961 NetNS:/var/run/netns/cni-bd5d4ce5-d2e8-9869-6cc2-ce1034b5c63d PortMappings:[] Networks:[]}
INFO[0000] About to add CNI network podman (type=bridge)
DEBU[0000] [0] CNI result: Interfaces:[{Name:cni0 Mac:0a:58:0a:58:00:01 Sandbox:} {Name:veth6e0bbce6 Mac:1e:0d:2b:90:92:ab Sandbox:} {Name:eth0 Mac:0a:58:0a:58:00:0b Sandbox:/var/run/netns/cni-bd5d4ce5-d2e8-9869-6cc2-ce1034b5c63d}], IP:[{Version:4 Interface:0xc4204c4108 Address:{IP:<IP_ADDRESS> Mask:ffff0000} Gateway:<IP_ADDRESS>}], Routes:[{Dst:{IP:<IP_ADDRESS> Mask:00000000} GW:<nil>}], DNS:{Nameservers:[] Domain: Search:[] Options:[]}
DEBU[0000] Running iptables command: -t filter -I FORWARD -s <IP_ADDRESS> ! -o <IP_ADDRESS> -j ACCEPT
DEBU[0000] /etc/system-fips does not exist on host, not mounting FIPS mode secret
WARN[0000] failed to parse language "en_US.UTF-8": language: tag is not well-formed
DEBU[0000] reading hooks from /usr/share/containers/oci/hooks.d
DEBU[0000] added hook /usr/share/containers/oci/hooks.d/oci-systemd-hook.json
DEBU[0000] added hook /usr/share/containers/oci/hooks.d/oci-umount.json
DEBU[0000] hook oci-systemd-hook.json did not match
DEBU[0000] hook oci-umount.json did not match
DEBU[0000] parsed reference into "[overlay@/var/lib/containers/storage+/var/run/containers/storage:overlay.override_kernel_check=true]@22c2dd5ee85dc01136051800684b0bf30016a3082f97093c806152bf43d4e089"
DEBU[0000] parsed reference into "[overlay@/var/lib/containers/storage+/var/run/containers/storage:overlay.override_kernel_check=true]@22c2dd5ee85dc01136051800684b0bf30016a3082f97093c806152bf43d4e089"
DEBU[0000] exporting opaque data as blob "sha256:22c2dd5ee85dc01136051800684b0bf30016a3082f97093c806152bf43d4e089"
DEBU[0000] parsed reference into "[overlay@/var/lib/containers/storage+/var/run/containers/storage:overlay.override_kernel_check=true]@22c2dd5ee85dc01136051800684b0bf30016a3082f97093c806152bf43d4e089"
DEBU[0000] exporting opaque data as blob "sha256:22c2dd5ee85dc01136051800684b0bf30016a3082f97093c806152bf43d4e089"
DEBU[0000] parsed reference into "[overlay@/var/lib/containers/storage+/var/run/containers/storage:overlay.override_kernel_check=true]@22c2dd5ee85dc01136051800684b0bf30016a3082f97093c806152bf43d4e089"
DEBU[0000] Setting CGroup path for container 74a2479af78c4348e8de40e7cfae9fb68939682a52bce2d36246ece091527961 to /libpod_parent/libpod-74a2479af78c4348e8de40e7cfae9fb68939682a52bce2d36246ece091527961
DEBU[0000] Created OCI spec for container 74a2479af78c4348e8de40e7cfae9fb68939682a52bce2d36246ece091527961 at /var/lib/containers/storage/overlay-containers/74a2479af78c4348e8de40e7cfae9fb68939682a52bce2d36246ece091527961/userdata/config.json
DEBU[0000] %s messages will be logged to syslog/usr/libexec/podman/conmon
DEBU[0000] running conmon: /usr/libexec/podman/conmon    args=[-c 74a2479af78c4348e8de40e7cfae9fb68939682a52bce2d36246ece091527961 -u 74a2479af78c4348e8de40e7cfae9fb68939682a52bce2d36246ece091527961 -r /usr/bin/runc -b /var/lib/containers/storage/overlay-containers/74a2479af78c4348e8de40e7cfae9fb68939682a52bce2d36246ece091527961/userdata -p /var/run/containers/storage/overlay-containers/74a2479af78c4348e8de40e7cfae9fb68939682a52bce2d36246ece091527961/userdata/pidfile -l /var/lib/containers/storage/overlay-containers/74a2479af78c4348e8de40e7cfae9fb68939682a52bce2d36246ece091527961/userdata/ctr.log --exit-dir /var/run/libpod/exits --socket-dir-path /var/run/libpod/socket -t --syslog]
DEBU[0000] Received container pid: 6173
DEBU[0000] Created container 74a2479af78c4348e8de40e7cfae9fb68939682a52bce2d36246ece091527961 in OCI runtime
DEBU[0000] Enabling signal proxying
DEBU[0000] Attaching to container 74a2479af78c4348e8de40e7cfae9fb68939682a52bce2d36246ece091527961
DEBU[0000] connecting to socket /var/run/libpod/socket/74a2479af78c4348e8de40e7cfae9fb68939682a52bce2d36246ece091527961/attach
DEBU[0000] Started container 74a2479af78c4348e8de40e7cfae9fb68939682a52bce2d36246ece091527961
DEBU[0000] Cleaning up container 74a2479af78c4348e8de40e7cfae9fb68939682a52bce2d36246ece091527961
DEBU[0000] Running iptables command: -t filter -D FORWARD -s <IP_ADDRESS> ! -o <IP_ADDRESS> -j ACCEPT
DEBU[0000] Tearing down network namespace at /var/run/netns/cni-bd5d4ce5-d2e8-9869-6cc2-ce1034b5c63d for container 74a2479af78c4348e8de40e7cfae9fb68939682a52bce2d36246ece091527961
INFO[0000] Got pod network &{Name:upbeat_jepsen Namespace:upbeat_jepsen ID:74a2479af78c4348e8de40e7cfae9fb68939682a52bce2d36246ece091527961 NetNS:/var/run/netns/cni-bd5d4ce5-d2e8-9869-6cc2-ce1034b5c63d PortMappings:[] Networks:[]}
INFO[0000] About to del CNI network podman (type=bridge)
DEBU[0000] unmounted container "74a2479af78c4348e8de40e7cfae9fb68939682a52bce2d36246ece091527961"
DEBU[0000] Storage is already unmounted, skipping...
DEBU[0000] Failed to unmount aa60a1ee147fb9f30010fff55ebea7e4ec2237aa4768654b52684dc3b9881885 overlay: /var/lib/containers/storage/overlay/aa60a1ee147fb9f30010fff55ebea7e4ec2237aa4768654b52684dc3b9881885/merged - invalid argument
[root@localhost vagrant]# echo $?
139
[root@localhost vagrant]# podman --version
podman version 0.7.3

@lukasheinrich Can you get any messages from conmon out of syslog?
It looks like the container is starting successfully and the application in the container is exiting with a 139, but I'd like the conmon logs to be certain.

journalctl -b | grep -i conmon

Jul 25 00:14:55 localhost.localdomain conmon[7567]: conmon 9d75cbd47d65fbefdd26 <ninfo>: addr{sun_family=AF_UNIX, sun_path=/tmp/conmon-term.F5MMMZ}
Jul 25 00:14:55 localhost.localdomain conmon[7567]: conmon 9d75cbd47d65fbefdd26 <ninfo>: about to waitpid: 7568
Jul 25 00:14:55 localhost.localdomain conmon[7567]: conmon 9d75cbd47d65fbefdd26 <ninfo>: about to accept from console_socket_fd: 9
Jul 25 00:14:55 localhost.localdomain conmon[7567]: conmon 9d75cbd47d65fbefdd26 <ninfo>: about to recvfd from connfd: 15
Jul 25 00:14:55 localhost.localdomain conmon[7567]: [82B blob data]
Jul 25 00:14:55 localhost.localdomain conmon[7567]: conmon 9d75cbd47d65fbefdd26 <ninfo>: container PID: 7576
Jul 25 00:14:55 localhost.localdomain conmon[7567]: conmon 9d75cbd47d65fbefdd26 <ninfo>: attach sock path: /var/run/libpod/socket/9d75cbd47d65fbefdd266d9e9688829d3b99ce526d83b6466664e821c1d6fb35/attach
Jul 25 00:14:55 localhost.localdomain conmon[7567]: conmon 9d75cbd47d65fbefdd26 <ninfo>: addr{sun_family=AF_UNIX, sun_path=/var/run/libpod/socket/9d75cbd47d65fbefdd266d9e9688829d3b99ce526d83b6466664e821c1d6fb35/attach}
Jul 25 00:14:55 localhost.localdomain conmon[7567]: conmon 9d75cbd47d65fbefdd26 <ninfo>: ctl fifo path: /var/lib/containers/storage/overlay-containers/9d75cbd47d65fbefdd266d9e9688829d3b99ce526d83b6466664e821c1d6fb35/userdata/ctl
Jul 25 00:14:55 localhost.localdomain conmon[7567]: conmon 9d75cbd47d65fbefdd26 <ninfo>: terminal_ctrl_fd: 16
Jul 25 00:14:55 localhost.localdomain conmon[7567]: conmon 9d75cbd47d65fbefdd26 <ninfo>: Accepted connection 18
Jul 25 00:14:55 localhost.localdomain conmon[7567]: conmon 9d75cbd47d65fbefdd26 <ninfo>: Got ctl message: 1 51 185
Jul 25 00:14:55 localhost.localdomain conmon[7567]: conmon 9d75cbd47d65fbefdd26 <ninfo>: Message type: 1, Height: 51, Width: 185
Jul 25 00:14:55 localhost.localdomain conmon[7567]: conmon 9d75cbd47d65fbefdd26 <ninfo>: container 7576 exited with status 139
Jul 25 00:14:55 localhost.localdomain conmon[7567]: conmon 9d75cbd47d65fbefdd26 <nwarn>: stdio_input read failed Input/output erro

I removed -it in case that would cause an issue
podman --log-level=debug run  busybox echo hello world

Jul 25 00:17:15 localhost.localdomain conmon[8032]: conmon 1ac46858ccfc8505e85c <ninfo>: about to waitpid: 8033
Jul 25 00:17:15 localhost.localdomain conmon[8032]: conmon 1ac46858ccfc8505e85c <ninfo>: container PID: 8041
Jul 25 00:17:15 localhost.localdomain conmon[8032]: conmon 1ac46858ccfc8505e85c <ninfo>: attach sock path: /var/run/libpod/socket/1ac46858ccfc8505e85c4fb29e62c013b6d5d3b65044877a0e222fec82da9a96/attach
Jul 25 00:17:15 localhost.localdomain conmon[8032]: conmon 1ac46858ccfc8505e85c <ninfo>: addr{sun_family=AF_UNIX, sun_path=/var/run/libpod/socket/1ac46858ccfc8505e85c4fb29e62c013b6d5d3b65044877a0e222fec82da9a96/attach}
Jul 25 00:17:15 localhost.localdomain conmon[8032]: conmon 1ac46858ccfc8505e85c <ninfo>: ctl fifo path: /var/lib/containers/storage/overlay-containers/1ac46858ccfc8505e85c4fb29e62c013b6d5d3b65044877a0e222fec82da9a96/userdata/ctl
Jul 25 00:17:15 localhost.localdomain conmon[8032]: conmon 1ac46858ccfc8505e85c <ninfo>: terminal_ctrl_fd: 16
Jul 25 00:17:15 localhost.localdomain conmon[8032]: conmon 1ac46858ccfc8505e85c <ninfo>: Accepted connection 18
Jul 25 00:17:15 localhost.localdomain conmon[8032]: conmon 1ac46858ccfc8505e85c <ninfo>: container 8041 exited with status 139

Could  you run a sh inside of busybox or does this fail also.  Do any podman run IMAGES work for you?

no all images I tried so far fail. See the vagrant box above, with that it should be possible to reproduce the behavior

I think this has to be runc - conmon seems to be working fine. Though, in the first logs, we have:
Jul 25 00:14:55 localhost.localdomain conmon[7567]: conmon 9d75cbd47d65fbefdd26 <nwarn>: stdio_input read failed Input/output erro
And that is a little concerning... but if it's only happening with -t -i and it fails without those it can't be the root cause.

Could be specific to how we're using runc, but that's not easy to test. I'll try your Vagrant box later today and see if I can replicate.

Docker uses an internal version of runc not the public one.
@mrunalp WDYT?

Could this be a bad version of runc?
#  podman run --rm -it busybox echo hello world
hello world
# rpm -q podman runc
podman-0.7.3-1.git0791210.fc27.x86_64
runc-1.0.0-36.gitad0f525.fc27.x86_64

i have the same
[vagrant@localhost ~]$ rpm -q podman runc
podman-0.7.3-1.git0791210.fc27.x86_64
runc-1.0.0-36.gitad0f525.fc27.x86_64
[vagrant@localhost ~]$ runc --version
runc version 1.0.0-rc5+dev
spec: 1.0.0
On Wed, Jul 25, 2018 at 3:41 PM Daniel J Walsh<EMAIL_ADDRESS>wrote:

Could this be a bad version of runc?
podman run --rm -it busybox echo hello world
hello world
rpm -q podman runc
podman-0.7.3-1.git0791210.fc27.x86_64
runc-1.0.0-36.gitad0f525.fc27.x86_64
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

It looks like the container process is hitting a segmentation fault. If we can gather the runc config.json then it will be easier to figure out why.

podman inspect $ctrid | grep StaticDir should print the path to the container's persistent files directory; inside that directory is config.json
@lukasheinrich Can you pastebin the contents of a container's config.json?

Sure, reopening

@lukasheinrich Sorry for the delay. That looks like the output of podman inspect - you should be looking for the config.json in the folder contained in StaticDir on line 30.

@mheon here's the config.json
https://gist.github.com/lukasheinrich/271222657b1d007389d26a288e263aac
Is there any Vagrantfile / spec that is known to work with podman? I tried both fedora-27 and fedora-28 without any luck.

FWIW manual container execution via

skopeo copy
umoci unpack
runc run

works

So this is specific to the way Podman is managing things, and also specific to Vagrant boxes (possible just Fedora vagrant boxes - I have a working podman on a RHEL vagrant box).

another data point: the podman preinstalled on the fedora/28-atomic-host  works fine

I am provisioning a vagrant box with the given Vagrantfile to attempt to replicate

Confirmed locally - exit status 139

Aug 06 20:42:06 localhost.localdomain conmon[4747]: conmon 1946512daa05cc22bad2 <ninfo>: container 4755 exited with status 139
The container itself is exiting

Aug 06 20:43:41 localhost.localdomain audit[4892]: AVC avc:  denied  { read write } for  pid=4892 comm="sleep" path="/dev/null" dev="tmpfs" ino=26140 scontext=system_u:system_r:container_t:s
@rhatdan I think we have an SELinux problem here

Confirmed - setenforce 0 allows the container to be started (though I still see an error trying to unmount it)

@mheon could you attach the entire AVC message?  THe one above is cut off.

The AVCs show me two things. One I am not sure  you have the latest container-selinux installed.
dnf reinstall container-selinux
And make sure it completes successfully.
You might need to update the libsemanage package or edit /etc/selinux/semanage.conf to change expand-check to be 0.  There was a bad version of libsemanage that was released that caused issues with containre-selinux.
It also looks like some content in the container is labeled var_lib_t?  Did you volume mount something in or is /var/lib/containers mislabeled.
restorecon -R -v /var/lib/containers

Labels on /var/lib/containers/ were all wrong - the restorecon seems to have resolved the issue.
@lukasheinrich Can you verify that the restorecon command above resolves the issue? I think we might have shipped a vagrant image with bad SELinux labels on part of the filesystem for F27

Thanks @mheon for finding the issue. I can confirm that setenforce 0 makes it work, but
[root@localhost vagrant]# podman --version
podman version 0.8.1
[root@localhost vagrant]# podman run --rm -it busybox echo hello world
[root@localhost vagrant]# echo $?
0
[root@localhost vagrant]# setenforce 0
[root@localhost vagrant]# podman run --rm -it busybox echo hello world
hello world
[root@localhost vagrant]# echo $?
0
[root@localhost vagrant]# setenforce 1
[root@localhost vagrant]# restorecon -R -v /var/lib/containers/
[root@localhost vagrant]# podman run --rm -it busybox echo hello world
[root@localhost vagrant]# echo $?
0

this is with a box
Vagrant.configure("2") do |config|
  config.vm.box = "fedora/28-cloud-base"
  config.vm.box_version = "20180425"
end

and after dnf install -y podman conmon (btw: shouldn't conmon be a dependency?)
Also, for rootless containers (the above was as root, but rootless also doesn't work  unless setenforce 0 it does), nothing gets written to /var/lib/containers so just the restorecon above seems to not be enough

PS: jut noticed this is now f28, but I can try again with f27 later

So restorecon is actually breaking things on F28? Fascinating.

@baude @lsm5 conmon is a dependency of Podman on F28 already, right?

Yes conmon is a dependency on F28.  We need a newer conmon which is why cri-o-1.11 is in updates testing.

@lukasheinrich What AVC's are you getting on the third example after setenforce 1
ausearch -m avc

@rhatdan https://gist.github.com/lukasheinrich/6e7c422ac924444045e109dfaba3645c

@lukasheinrich These are the same AVC's that @mheon showed me.
The issue again is that container-selinux did not install correctly.
dnf -y update libsemanage container-selinux
dnf -y reinstall container-selinux
restorecon -R -v /var/lib/containers

@rhatdan confirmed. both rootful and rootless containers work with this. So is the issue with the vagrant image or with podman?

thanks @mheon can the images be fixed (not sure what the process is for updating vagrant images)

@dustymabe @lsm5 Any ideas on how to fix this?

With the F27 image, it is definitely the vagrant image - SELinux labels were wrong on /var/lib/containers in the image as shipped. Can't say for certain about F28, but I'm inclined to believe that one could be a similar case.

we don't release updated cloud base images. We'd like to but we don't today. We do release updated atomic host images so those should work fine. Could we possibly work around this with a RPM %post ?

We'd need a restorecon on the CRI-O and Podman RPMs in post, probably Skopeo too. I don't know how expensive this really is - if we're tacking 5 minutes on every time you install a Podman RPM it might not be a good idea.

We could do something in the container-selinux package so that eveyone gets the benefit, but this could be an expensive operation.  I guess we could set a trigger so that it only happens once when updating the current container-selinux package.

Is this just an issue on F27 or F28 as well?

It's F28 as well.
On Thu, Aug 9, 2018 at 8:54 PM Daniel J Walsh<EMAIL_ADDRESS>wrote:

Is this just an issue on F27 or F28 as well?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/projectatomic/libpod/issues/1118#issuecomment-411860568,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACNfA9vW0Eszs_nNdJ1Jc_7eAKW55QaRks5uPIVmgaJpZM4VXFdP
.

Is this still an issue?

I fixed container-selinux to do a better job with this.  I will close and people can reopen if they see other issues.


Feature Request: Self-reference

It would be great if I could reference one entry on another in the same table?
So that one column in the table can be a reference on the ID of the same.

This should be already supported, but the collection need to be saved first.
The relations management UI will be refactored in v0.12/v0.13 together with https://github.com/pocketbase/pocketbase/issues/976.

Ah alright. Than sry for the interuption :)


Can spring data jdbc add automatic table creation?

See https://docs.spring.io/spring-data/relational/reference/jdbc/schema-support.html.


Add registers::debug

Fixes https://github.com/rust-osdev/x86_64/issues/284.
This adds registers::debug.

Dr0-Dr3 implement DebugAddressRegister.
Dr6Flags can be read from Dr6.

For Dr7 I added Dr7Value which contain Dr7Flags but has functions to modify the bits corresponding to the condition and size fields. Via Dr7Value::flags_mut, you can modify flags in place.

Rebased on latest master.

Thanks a lot for the review! I addressed all small issues and have added my thoughts on the big remaining one.

Thanks a lot for your reviews and sorry for the wait! I addressed all comments and would appreciate another round of reviews. :)

LGTM, the only thing we might want to change is the fact that we have really long names starting with Debug, given that the module is also called debug. So it might make sense to shorten the names to remove the Debug prefix.
@Freax13 your thoughts?

I think we should keep the prefix, this only affects two types and the names might sound a bit too generic without the Debug prefix (AddressRegister, AddressRegisterNumber). I'd rather we strip the Hw prefix from HwBreakpointCondition and HwBreakpointSize, it's a bit unidiomatic to use abbreviations in type names and it should be pretty clear that those types are meant for hardware breakpoints anyways.

Thank you for your contribution! :partying_face:

:partying_face: Thanks for your help!

Would it be possible to have a 0.14.10 release containing these additions? It would help us out a lot. :)

I created a release PR at https://github.com/rust-osdev/x86_64/pull/386.


gRPC Tutorial: Add client code gen details

Internal Review
Fixes #24819
Added a little more detail on what grpc.tools is generating so it is clear where to find the two .cs files it creates based on the .proto file per customer request.

@James, I didn't want to go into too much detail on the generated files and then bog down the tutorial, but I agree with the customer that some more was needed.  See if that feels like the right balance to you.

This is what the doc looks like now:

It's a bit confusing about what are required steps to get the app working vs additional information. What do you think of putting the new content in an [!INFO] to make it clearer?

Good idea.  You are right, it was getting too busy attempting to put in inline.

@JamesNK.  I put the new content in a [!Note] section.   Look OK?

Hi @JamesNK, is this OK to publish?  ( I didn't see a review approval yet. )
I put the new content in a [!Note] section as was suggested.
Here is a review link directly to that section
Thanks so much for the feedback and help.


fix(android): throw error when value is null

Summary:
Android did not show errors when null/undefined values were passed. This PR fixes that.
Closes #253
Test Plan:

Try setting a  null/undefined value to AsyncStorage.
Note that errors where thrown.

@tido64 Checks are not done in get/set functions, where passing null or undefined as value throws an error from JS (it would be thrown from Native either way).

Thanks, @Krizzu ❤


ROS2 Suppot for Slamtec Mapper Lidar

Hi there, just wondering if this repo support Mapper Lidar, or you have a plan to release ROS2 package for it.

Keen for M2M2 support too.


fix account-change text overflowing outside menu

Coverage remained the same at 52.786% when pulling a6e83efe2136a947bcb7b60e6fca83c64fd94eed on nazaninreihani:menu-change-account into f75a638d9f682591b2907c26b1dfe9f767eb1076 on binary-com:dev.


Сreating an array of unique values in JavaScript using Sets with empty arrays in the array

const a = [...new Set([ [ ], [ ] ]) ]
// a = [ [ ], [ ] ];

That's because [] !== []. A JavaScript object value doesn't store the object itself, but a reference (pointer) to it, so if the references are different, the arrays are different and unique.

It is clear. But it violates the concept of Set itself.

How so?
Not saying this is the definition, but if we take this one:

Set objects are collections of values. You can iterate through the elements of a set in insertion order. A value in the Set may only occur once; it is unique in the Set's collection

Then it isn't violating the concept of Set since the values are unique, you are passing in javascript references to objects by design and [] an object.  Those things are different no matter how you look at them, so the set should contain both.
What would happen if it wasn't true we wrote instead?
const a = [];
const b = [];
const c = new Set([a, b]);
a.push(2);
b.push(1);
// c = [ [1] ]; or c = [ [2] ]; Which would expect? or do you expect c = [ [] ];?

And if we move the definition of c lower?
const a = [];
const b = [];
a.push(2);
b.push(1);
const c = new Set([a, b]);
// c = [ [1], [2] ];

Why would moving the point in which the set is created have an impact on the references saved.
The current functionality makes way more sense.

This would be true if new Set kept a reference to the original array and handles it changes, but it is not so. You want to get a set of unique values here and now but not for the future with taking into account their possible changes. Imagine f.e. that you have an array of arrays and each of them contains longitude and latitude of some point at the map (two floats) - and you can't create array with unique values with Set in this case.

and handles it changes, but it is not so.

Can you explain this?

That would seem to contradict your statement.
Just because it can't be used to find the unique points on a x/y coordinate plan in YOUR representation has nothing to do with whether or not the functionality is expected.
for instance, if you just change the initial setup it works fine. Instead of what you said, just instead say this:

Imagine f.e. that you have an array of strings which contain longitude and latitude of some point at the map

Then you CAN create an Set which removes duplicates.
warren@palladium:~$ node
> const a = 'x=0;y=0';
undefined
> const b = 'x=0;y=0';
undefined
> new Set([a, b]);
Set { 'x=0;y=0' }
>

The Set has references to the elements of the array on the basis of which it was created, but it does not track changes in the array itself:
`const a = [];
const b = [];
const c = [];
const data = [a,b];

const set = new Set(data);
console.log({ set, data });
data.push(c);
console.log({ set, data });`

You persistently don't want to notice that the Set does not work properly with composite data types, at the least, it's behavior is unexpected in this case.
It wasn't not about solving this problem in principle — it is easily solved. it's that you cannot solve it in this way without resorting to additional transformations of the source data


Generating new playground not working

SwiftPlaygroundsCLI Environment

SwiftPlaygroundsCLI version: 1.0.0
macOS version: 10.15.5
Xcode version: Version 11.5 (11E608c)
Installed via (mint, brew): brew

What did you do?
swiftplayground new test
What did you expect to happen?
Generate a new playground
What happened instead?
Error: Error Domain=NSCocoaErrorDomain Code=260 "The file “BlankWithModules.playgroundbook” couldn’t be opened because there is no such file." UserInfo={NSFilePath=/Applications/Playgrounds.app/Contents/Resources/Templates/BlankWithModules.playgroundbook, NSUnderlyingError=0x7fe92860f4a0 {Error Domain=NSPOSIXErrorDomain Code=2 "No such file or directory"}}

Hey @MysteryCoder456,
thanks for opening up an issue on SwiftPlaygroundsCLI.
It seems like the directory ~/Library/Mobile\ Documents/iCloud~com~apple~Playgrounds/Documents/ is missing.
A simple fix is to start the Playgrounds.app on your mac so that a Documents directory will be created in the iCloud container of the Playgrounds.app. After that you should be able to use SwiftPlaygroundsCLI.
I've just added a fix which will create the Documents directory if it is missing. It will be available within the next release of SwiftPlaygroundsCLI.

Please try it again with the latest release 1.0.2

Thanks for the reply and fix.

Sadly that didn't work. The Playgrounds folder is already there but the error is happening anyway.

I've just reproduced it and the version 1.0.2 fixes that problem.
Could you ensure you are running version 1.0.2.

I've upgraded to 1.0.2 and still getting the same error. Also, running swiftplaygrounds --version shows Version 1.0.0 even thoough I upgraded to 1.0.2.

Yes you are correct. The version has not been properly updated when initializing SwiftCLI.
This will be fixed with the next release.
If the problem still exists please try to re-install the Playgrounds.app from the Mac AppStore and ensure the following file exists:
/Applications/Playgrounds.app/Contents/Resources/Templates/BlankWithModules.playgroundbook
And a documents directory is created in the iCloud container of the Playgrounds.app
~/Library/Mobile Documents/iCloud~com~apple~Playgrounds/Documents/

Oh, you need the Playgrounds app? I thought this was usable without any apps, that's why I installed it in the first place XD.

Correct you need the Playgrounds.app from the Mac AppStore 👍
I will update the Installation section in the ReadMe to clarify the installation requirements.


Source for lib/services/*.coffee?

It looks like a link is broken

yep, need to fix.

in the meantime take a look at https://github.com/chaplinjs/facebook-example/commit/c76445f4089697e7dd0d3ce1c9ffe027186241bb please


Xcode 12.5 requires macOS 11

The next version of Xcode (12.5) will require macOS 11 to run as noted in the release notes

It still in beta, but we can expect to have stable release in the next 1 or 2 weeks.
Will the macOS 11 be out of private preview when that happens?

Some details here https://github.com/actions/virtual-environments/issues/2486#issuecomment-782034281

Hi @diogot!
I'm going to close the issue since we already have Xcode-12.5 on macOS 11 image. Please feel free to ask questions in the https://github.com/actions/virtual-environments/issues/2486
Thank you!


Remove implicit root nodes from bevy_ui

Objective

Make bevy_ui "root" nodes more intuitive to use/style by removing the implicit flexbox styling (such as stretch alignment) that is applied to them because bevy_ui is implicitly inserting an extra root node above the user-specified "root". nodes are currently not actually the root Taffy node.

Solution

Remove the implicit root node, and rather than storing the user-specified root nodes as children of the implicit root node, store a separate Vec of root nodes.
Use the window's size as the available_space parameter to Taffy.compute_layout rather than setting it on the implicit root node.

Changelog

Bevy UI no longer creates an implicit root node above the user-specified root node.

Migration Guide

Bevy UI no longer creates an implicit root node above the user-specified root node. You may need to add height: Val::Percent(100.) to your root nodes if you were previously relying on being implicitly set.

There seem to be quite a few more examples that were relying on this behavior.

@rparrett How did you generate those visual diffs? That's very helpful!
I've fixed a bunch of the examples (mostly just adding height: Val::Percent(100.0) to the root node - but in a few cases actually adding a wrapper root node). But looking at some of the other examples, I think perhaps we ought to be block this on https://github.com/DioxusLabs/taffy/issues/530. The reason being that it seems common to position top-level UI nodes using absolute positioning (this is especially used in examples for debug text), and  this PR would currently break that functionality (but if we land https://github.com/DioxusLabs/taffy/issues/530, then that would continue to "just work").
As an aside: I experienced a lot of issues with click detection not working (i.e. buttons not doing anything when clicked) when testing examples. But it seems this is also the case on main and is not related to this PR.

 I hacked together this thing to generate a super basic html report from those.
This takes a good while to do the screenshotting part and your PC pretty difficult to use with windows popping up and stealing focus while it is happening. Patching in https://github.com/bevyengine/bevy/pull/9220 helps a bit with the UI examples that run with desktop_app mode.

This seems good. The only snag is root node styling, waiting for https://github.com/DioxusLabs/taffy/issues/530 seems sensible.
I haven't checked all the examples but the ones I looked at seemed fine except for the problem with the margins in game_menu.

https://github.com/DioxusLabs/taffy/issues/530 has ended up being more complicated than anticipated (mostly because web treats root nodes as display: block - so we either need to implement that or some kind of switch for compatibility).
My suggestion is to re-add the implicit roots, but:

Create an implicit root per user-specified root (rather than having all user-specified roots under a single root node). This preserves the benefit provided by this PR of having user-specified root nodes layout entirely independently of each other).
Make the implicit root nodes display: grid; align-items: start; justify-items: start.

I think this will provide the most user-friendly environment for people to create their UIs in while not requiring us to wait on Taffy changes.

I have re-written this PR to use the above approach (https://github.com/bevyengine/bevy/pull/9637#issuecomment-1719209238) + updated the description to match the new approach. This seems to have fixed the examples. None of the following look related to this PR to me (they all just look like non-deterministic examples).

The only issue seems to be the game_menu example which does appear to be a regression from main. Although I am struggling to understand how this PR could be causing that, as it seems to not be related to the root node.

None of the following look related to this PR to me (they all just look like non-deterministic examples).

Yeah. shadow_biases is deterministic if there is no mouse movement, but the diff shows identical UI. Some have inherent non-deterministic randomness and I think a few others just behave differently based on asset load timing.

Yeah. shadow_biases is deterministic if there is no mouse movement, but the diff shows identical UI.

Yeah, I was trying to still use my computer while it ran, so a lot of them did have mouse movements! As you say, none of the diffs seem to be in UI elements (except font_atlas_debug, but that seems to be rendering random glyphs so it's never going to be consistent).

Yeah I have a similar problem with my latest borders reimplementation that causes the last word from blocks of text to vanish. I don't think we should let it block this PR, I haven't looked at the latest changes closely yet but the direction seems good. Just get everything else right and I'll take another look at text and see if I can fix it properly.

It was the layout rounding, of course. I think I have a workaround, got to go out now but I'll put out a PR this evening.

It's the layout rounding. I think I have a workaround, I'll put up a PR this evening.

Worked for my problems. but not the menu example here.
I'm convinced the problem with the menu is nothing to do with this PR anyway, it's an existing bug revealed by these changes.

This seems to break the multiple_windows example now.

This seems to break the multiple_windows example now with a runtime panic.

Good idea to check that. Fixed!

Before vs. After screenshot:


Can't start 100 nixos-containers

Issue description
I want to start 100 identical containers on NixOS.
I have already raised the inotify max_user_instances limit like suggested in https://github.com/NixOS/nixpkgs/issues/36214.
  boot.kernel.sysctl = {
    # Fix "Failed to allocate directory watch: Too many open files"
    # or "Insufficent watch descriptors available."
    "fs.inotify.max_user_instances" = 8192;
  };

That helped to get 40 containers running, but 100 explode shortly after start.
Here are the log lines from a single container:
[davidak@ethmoid:~]$ grep target18 journal.log
Jul 17 13:37:29 targets-host systemd[1]: Starting Container 'target18'...
Jul 17 13:37:36 targets-host container target18[1906]: Spawning container target18 on /var/lib/containers/target18.
Jul 17 13:37:36 targets-host container target18[1906]: Press ^] three times within 1s to kill container.
Jul 17 13:37:37 targets-host kernel: IPv6: ADDRCONF(NETDEV_UP): vb-target18: link is not ready
Jul 17 13:37:37 targets-host kernel: br0: port 2(vb-target18) entered blocking state
Jul 17 13:37:37 targets-host kernel: br0: port 2(vb-target18) entered disabled state
Jul 17 13:37:37 targets-host kernel: device vb-target18 entered promiscuous mode
Jul 17 13:37:37 targets-host systemd-machined[1901]: New machine target18.
Jul 17 13:37:40 targets-host kernel: IPv6: ADDRCONF(NETDEV_CHANGE): vb-target18: link becomes ready
Jul 17 13:37:40 targets-host kernel: br0: port 2(vb-target18) entered blocking state
Jul 17 13:37:40 targets-host kernel: br0: port 2(vb-target18) entered forwarding state
Jul 17 13:37:41 targets-host container target18[1906]: <<< NixOS Stage 2 >>>
Jul 17 13:37:47 targets-host container target18[1906]: tee: /proc/self/fd/10: No such device or address
Jul 17 13:38:44 targets-host container target18[1906]: starting systemd...
Jul 17 13:38:44 targets-host container target18[1906]: systemd 239 running in system mode. (+PAM +AUDIT -SELINUX +IMA +APPARMOR +SMACK -SYSVINIT +UTMP -LIBCRYPTSETUP +GCRYPT -GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID -ELFUTILS +KMOD +IDN2 -IDN +PCRE2 default-hierarchy=hybrid)
Jul 17 13:38:44 targets-host container target18[1906]: Detected virtualization systemd-nspawn.
Jul 17 13:38:44 targets-host container target18[1906]: Detected architecture x86-64.
Jul 17 13:38:44 targets-host container target18[1906]: [1B blob data]
Jul 17 13:38:44 targets-host container target18[1906]: Welcome to NixOS 19.03.172979.8634c3b6199 (Koi)!
Jul 17 13:38:44 targets-host container target18[1906]: [1B blob data]
Jul 17 13:38:44 targets-host container target18[1906]: Set hostname to <target18>.
Jul 17 13:38:44 targets-host container target18[1906]: Initializing machine ID from container UUID.
Jul 17 13:38:44 targets-host container target18[1906]: Failed to install release agent, ignoring: No such file or directory
Jul 17 13:38:45 targets-host container target18[1906]: File /nix/store/64w1hwm93r0bnbrq6dwprnqlc5dwaplj-systemd-239.20190219/example/systemd/system/systemd-journald.service:36 configures an IP firewall (IPAddressDeny=any), but the local system does not support BPF/cgroup based firewalling.
Jul 17 13:38:45 targets-host container target18[1906]: Proceeding WITHOUT firewalling in effect! (This warning is only shown for the first loaded unit using IP firewalling.)
Jul 17 13:38:46 targets-host container target18[1906]: [  OK  ] Listening on Journal Socket.
Jul 17 13:38:46 targets-host container target18[1906]:          Mounting POSIX Message Queue File System...
Jul 17 13:38:46 targets-host container target18[1906]: [  OK  ] Reached target Swap.
Jul 17 13:38:46 targets-host container target18[1906]:          Starting Update UTMP about System Boot/Shutdown...
Jul 17 13:38:46 targets-host container target18[1906]: [  OK  ] Started Dispatch Password Requests to Console Directory Watch.
Jul 17 13:38:46 targets-host container target18[1906]: [  OK  ] Reached target All Network Interfaces (deprecated).
Jul 17 13:38:46 targets-host container target18[1906]: [  OK  ] Reached target Remote File Systems.
Jul 17 13:38:46 targets-host container target18[1906]:          Mounting Huge Pages File System...
Jul 17 13:38:46 targets-host container target18[1906]: [  OK  ] Created slice User and Session Slice.
Jul 17 13:38:46 targets-host container target18[1906]: [  OK  ] Reached target Slices.
Jul 17 13:38:46 targets-host container target18[1906]: [  OK  ] Listening on Journal Socket (/dev/log).
Jul 17 13:38:46 targets-host container target18[1906]:          Starting Journal Service...
Jul 17 13:38:46 targets-host container target18[1906]: [  OK  ] Started Forward Password Requests to Wall Directory Watch.
Jul 17 13:38:46 targets-host container target18[1906]: [  OK  ] Reached target Paths.
Jul 17 13:38:46 targets-host container target18[1906]: [  OK  ] Reached target Local File Systems (Pre).
Jul 17 13:38:46 targets-host container target18[1906]: [  OK  ] Reached target Local File Systems.
Jul 17 13:38:46 targets-host container target18[1906]:          Starting Rebuild Journal Catalog...
Jul 17 13:38:46 targets-host container target18[1906]:          Starting Apply Kernel Variables...
Jul 17 13:38:46 targets-host container target18[1906]: [  OK  ] Created slice system-getty.slice.
Jul 17 13:38:46 targets-host container target18[1906]: [  OK  ] Listening on initctl Compatibility Named Pipe.
Jul 17 13:38:47 targets-host container target18[1906]: [  OK  ] Mounted POSIX Message Queue File System.
Jul 17 13:38:47 targets-host container target18[1906]: [  OK  ] Mounted Huge Pages File System.
Jul 17 13:38:47 targets-host container target18[1906]: [  OK  ] Started Apply Kernel Variables.
Jul 17 13:38:47 targets-host container target18[1906]:          Starting Networking Setup...
Jul 17 13:38:47 targets-host container target18[1906]: [  OK  ] Started Update UTMP about System Boot/Shutdown.
Jul 17 13:38:47 targets-host container target18[1906]: [  OK  ] Started Rebuild Journal Catalog.
Jul 17 13:38:47 targets-host container target18[1906]:          Starting Update is Completed...
Jul 17 13:38:48 targets-host container target18[1906]: [  OK  ] Started Journal Service.
Jul 17 13:38:48 targets-host container target18[1906]:          Starting Flush Journal to Persistent Storage...
Jul 17 13:38:48 targets-host container target18[1906]: [  OK  ] Started Update is Completed.
Jul 17 13:38:48 targets-host container target18[1906]: [  OK  ] Reached target System Initialization.
Jul 17 13:38:48 targets-host container target18[1906]: [  OK  ] Listening on SSH Socket.
Jul 17 13:38:48 targets-host container target18[1906]: [  OK  ] Started Daily Cleanup of Temporary Directories.
Jul 17 13:38:48 targets-host container target18[1906]: [  OK  ] Reached target Timers.
Jul 17 13:38:48 targets-host container target18[1906]: [  OK  ] Listening on D-Bus System Message Bus Socket.
Jul 17 13:38:48 targets-host container target18[1906]: [  OK  ] Reached target Sockets.
Jul 17 13:38:48 targets-host container target18[1906]: [  OK  ] Reached target Basic System.
Jul 17 13:38:48 targets-host container target18[1906]:          Starting Name Service Cache Daemon...
Jul 17 13:38:48 targets-host container target18[1906]:          Starting DHCP Client...
Jul 17 13:38:49 targets-host container target18[1906]: [  OK  ] Started Flush Journal to Persistent Storage.
Jul 17 13:38:49 targets-host container target18[1906]:          Starting Create Volatile Files and Directories...
Jul 17 13:38:50 targets-host container target18[1906]: [  OK  ] Started Create Volatile Files and Directories.
Jul 17 13:38:54 targets-host container target18[1906]: [  OK  ] Started D-Bus System Message Bus.
Jul 17 13:38:58 targets-host container target18[1906]: [  OK  ] Started Name Service Cache Daemon.
Jul 17 13:38:58 targets-host container target18[1906]: [  OK  ] Reached target Host and Network Name Lookups.
Jul 17 13:38:58 targets-host container target18[1906]: [  OK  ] Reached target User and Group Name Lookups.
Jul 17 13:38:58 targets-host container target18[1906]:          Starting Login Service...
Jul 17 13:39:00 targets-host container target18[1906]: [  OK  ] Started Login Service.
Jul 17 13:39:00 targets-host container target18[1906]: [  OK  ] Started Networking Setup.
Jul 17 13:39:00 targets-host container target18[1906]:          Starting Extra networking commands....
Jul 17 13:39:02 targets-host container target18[1906]: [  OK  ] Started Extra networking commands..
Jul 17 13:39:09 targets-host systemd[1]<EMAIL_ADDRESS>Start operation timed out. Terminating.
Jul 17 13:39:20 targets-host container target18[1906]: [1.8K blob data]
Jul 17 13:39:20 targets-host container target18[1906]: [  OK  ] Stopped Name Service Cache Daemon.
Jul 17 13:39:22 targets-host container target18[1906]:          Starting Name Service Cache Daemon...
Jul 17 13:39:28 targets-host container target18[1906]: [515B blob data]
Jul 17 13:39:28 targets-host container target18[1906]: [  OK  ] Reached target Network.
Jul 17 13:39:28 targets-host container target18[1906]:          Starting Nginx Web Server...
Jul 17 13:39:29 targets-host container target18[1906]:          Starting Permit User Sessions...
Jul 17 13:39:29 targets-host container target18[1906]:          Starting Dnsmasq Daemon...
Jul 17 13:39:29 targets-host container target18[1906]: [  OK  ] Reached target Network is Online.
Jul 17 13:39:30 targets-host container target18[1906]: [  OK  ] Started Permit User Sessions.
Jul 17 13:39:30 targets-host container target18[1906]: [  OK  ] Started Console Getty.
Jul 17 13:39:30 targets-host container target18[1906]: [  OK  ] Reached target Login Prompts.
Jul 17 13:39:37 targets-host container target18[1906]: [2B blob data]
Jul 17 13:39:37 targets-host container target18[1906]: [1B blob data]
Jul 17 13:39:37 targets-host container target18[1906]: <<< Welcome to NixOS 19.03.172979.8634c3b6199 (x86_64) - console >>>
Jul 17 13:39:37 targets-host container target18[1906]: [1B blob data]
Jul 17 13:39:37 targets-host container target18[1906]: Run `nixos-help` for the NixOS manual.
Jul 17 13:39:37 targets-host container target18[1906]: [1B blob data]
Jul 17 13:40:39 targets-host systemd[1]<EMAIL_ADDRESS>State 'stop-sigterm' timed out. Killing.
Jul 17 13:40:39 targets-host systemd[1]<EMAIL_ADDRESS>Killing process 1906 (systemd-nspawn) with signal SIGKILL.
Jul 17 13:40:39 targets-host systemd[1]<EMAIL_ADDRESS>Killing process 2816 (systemd) with signal SIGKILL.
Jul 17 13:40:39 targets-host systemd[1]<EMAIL_ADDRESS>Killing process 23579 (systemd-journal) with signal SIGKILL.
Jul 17 13:40:39 targets-host systemd[1]<EMAIL_ADDRESS>Killing process 31045 (dhcpcd) with signal SIGKILL.
Jul 17 13:40:39 targets-host systemd[1]<EMAIL_ADDRESS>Killing process 25020 (dbus-daemon) with signal SIGKILL.
Jul 17 13:40:39 targets-host systemd[1]<EMAIL_ADDRESS>Killing process 25659 (systemd-logind) with signal SIGKILL.
Jul 17 13:40:39 targets-host systemd[1]<EMAIL_ADDRESS>Killing process 32311 (nscd) with signal SIGKILL.
Jul 17 13:40:39 targets-host systemd[1]<EMAIL_ADDRESS>Killing process 3336 (nginx) with signal SIGKILL.
Jul 17 13:40:39 targets-host systemd[1]<EMAIL_ADDRESS>Killing process 3975 (nginx) with signal SIGKILL.
Jul 17 13:40:39 targets-host systemd[1]<EMAIL_ADDRESS>Killing process 2755 (dnsmasq) with signal SIGKILL.
Jul 17 13:40:39 targets-host systemd[1]<EMAIL_ADDRESS>Killing process 31530 (agetty) with signal SIGKILL.
Jul 17 13:40:39 targets-host container target18[1906]: target18 login:
Jul 17 13:40:39 targets-host systemd[1]<EMAIL_ADDRESS>Main process exited, code=killed, status=9/KILL
Jul 17 13:40:39 targets-host systemd[1]<EMAIL_ADDRESS>Killing process 2816 (systemd) with signal SIGKILL.
Jul 17 13:40:39 targets-host systemd[1]<EMAIL_ADDRESS>Killing process 31045 (dhcpcd) with signal SIGKILL.
Jul 17 13:40:39 targets-host systemd[1]<EMAIL_ADDRESS>Killing process 25020 (dbus-daemon) with signal SIGKILL.
Jul 17 13:40:39 targets-host systemd[1]<EMAIL_ADDRESS>Killing process 3975 (nginx) with signal SIGKILL.
Jul 17 13:40:39 targets-host systemd[1]<EMAIL_ADDRESS>Killing process 2755 (dnsmasq) with signal SIGKILL.
Jul 17 13:40:39 targets-host systemd[1]<EMAIL_ADDRESS>Killing process 31530 (agetty) with signal SIGKILL.
Jul 17 13:40:40 targets-host systemd[1]<EMAIL_ADDRESS>Failed with result 'timeout'.
Jul 17 13:40:40 targets-host systemd[1]: Failed to start Container 'target18'.
Jul 17 13:40:40 targets-host systemd[1]<EMAIL_ADDRESS>Consumed 10.513s CPU time
Jul 17 13:40:40 targets-host kernel: br0: port 2(vb-target18) entered disabled state
Jul 17 13:40:40 targets-host systemd[1]<EMAIL_ADDRESS>Service RestartSec=100ms expired, scheduling restart.
Jul 17 13:40:40 targets-host systemd[1]<EMAIL_ADDRESS>Scheduled restart job, restart counter is at 1.
Jul 17 13:40:40 targets-host systemd[1]: Stopped Container 'target18'.
Jul 17 13:40:40 targets-host systemd[1]<EMAIL_ADDRESS>Consumed 10.513s CPU time
Jul 17 13:40:40 targets-host systemd[1]: Starting Container 'target18'...
Jul 17 13:40:41 targets-host kernel: device vb-target18 left promiscuous mode
Jul 17 13:40:41 targets-host kernel: br0: port 2(vb-target18) entered disabled state
Jul 17 13:40:45 targets-host container target18[12470]: Spawning container target18 on /var/lib/containers/target18.

Jul 17 13:40:47 targets-host kernel: IPv6: ADDRCONF(NETDEV_UP): vb-target18: link is not ready
Jul 17 13:40:47 targets-host kernel: br0: port 31(vb-target18) entered blocking state
Jul 17 13:40:47 targets-host kernel: br0: port 31(vb-target18) entered disabled state
Jul 17 13:40:47 targets-host kernel: device vb-target18 entered promiscuous mode
Jul 17 13:40:47 targets-host kernel: br0: port 31(vb-target18) entered blocking state
Jul 17 13:40:47 targets-host kernel: br0: port 31(vb-target18) entered forwarding state
Jul 17 13:40:47 targets-host kernel: br0: port 31(vb-target18) entered disabled state
Jul 17 13:40:49 targets-host container target18[12470]: Failed to register machine: Machine 'target18' already exists
Jul 17 13:40:50 targets-host kernel: br0: port 31(vb-target18) entered disabled state
Jul 17 13:40:50 targets-host kernel: device vb-target18 left promiscuous mode
Jul 17 13:40:50 targets-host kernel: br0: port 31(vb-target18) entered disabled state
Jul 17 13:40:51 targets-host systemd[1]<EMAIL_ADDRESS>Main process exited, code=exited, status=1/FAILURE
Jul 17 13:40:51 targets-host systemd[1]<EMAIL_ADDRESS>Failed with result 'exit-code'.
Jul 17 13:40:51 targets-host systemd[1]: Failed to start Container 'target18'.
Jul 17 13:40:51 targets-host systemd[1]<EMAIL_ADDRESS>Consumed 637ms CPU time
Jul 17 13:40:51 targets-host systemd[1]<EMAIL_ADDRESS>Service RestartSec=100ms expired, scheduling restart.
Jul 17 13:40:51 targets-host systemd[1]<EMAIL_ADDRESS>Scheduled restart job, restart counter is at 2.
Jul 17 13:40:52 targets-host systemd[1]: Stopped Container 'target18'.
Jul 17 13:40:52 targets-host systemd[1]<EMAIL_ADDRESS>Consumed 637ms CPU time
Jul 17 13:40:52 targets-host systemd[1]: Starting Container 'target18'...
Jul 17 13:40:55 targets-host container target18[14004]: Spawning container target18 on /var/lib/containers/target18.

Jul 17 13:40:56 targets-host kernel: IPv6: ADDRCONF(NETDEV_UP): vb-target18: link is not ready
Jul 17 13:40:56 targets-host kernel: br0: port 2(vb-target18) entered blocking state
Jul 17 13:40:56 targets-host kernel: br0: port 2(vb-target18) entered disabled state
Jul 17 13:40:56 targets-host kernel: device vb-target18 entered promiscuous mode
Jul 17 13:40:56 targets-host kernel: br0: port 2(vb-target18) entered blocking state
Jul 17 13:40:56 targets-host kernel: br0: port 2(vb-target18) entered forwarding state
Jul 17 13:40:57 targets-host kernel: br0: port 2(vb-target18) entered disabled state
Jul 17 13:40:59 targets-host container target18[14004]: Failed to register machine: Machine 'target18' already exists
Jul 17 13:40:59 targets-host container target18[14004]: Parent died too early
Jul 17 13:40:59 targets-host kernel: br0: port 2(vb-target18) entered disabled state
Jul 17 13:40:59 targets-host kernel: device vb-target18 left promiscuous mode
Jul 17 13:40:59 targets-host kernel: br0: port 2(vb-target18) entered disabled state
Jul 17 13:41:01 targets-host systemd[1]<EMAIL_ADDRESS>Failed with result 'exit-code'.
Jul 17 13:41:01 targets-host systemd[1]: Failed to start Container 'target18'.
Jul 17 13:41:08 targets-host container target18[15779]: Spawning container target18 on /var/lib/containers/target18.
Jul 17 13:41:08 targets-host container target18[15779]: Press ^] three times within 1s to kill container.
Jul 17 13:41:08 targets-host kernel: IPv6: ADDRCONF(NETDEV_UP): vb-target18: link is not ready
Jul 17 13:41:08 targets-host kernel: br0: port 44(vb-target18) entered blocking state
Jul 17 13:41:08 targets-host kernel: br0: port 44(vb-target18) entered disabled state
Jul 17 13:41:08 targets-host kernel: device vb-target18 entered promiscuous mode
Jul 17 13:41:08 targets-host kernel: br0: port 44(vb-target18) entered blocking state
Jul 17 13:41:08 targets-host kernel: br0: port 44(vb-target18) entered forwarding state
Jul 17 13:41:09 targets-host kernel: br0: port 44(vb-target18) entered disabled state
Jul 17 13:41:10 targets-host container target18[15779]: Failed to register machine: Machine 'target18' already exists
Jul 17 13:41:10 targets-host kernel: br0: port 44(vb-target18) entered disabled state
Jul 17 13:41:10 targets-host kernel: device vb-target18 left promiscuous mode
Jul 17 13:41:10 targets-host kernel: br0: port 44(vb-target18) entered disabled state
Jul 17 13:41:11 targets-host systemd[1]<EMAIL_ADDRESS>Main process exited, code=exited, status=1/FAILURE
Jul 17 13:41:11 targets-host systemd[1]<EMAIL_ADDRESS>Failed with result 'exit-code'.
Jul 17 13:41:11 targets-host systemd[1]: Failed to start Container 'target18'.
Jul 17 13:41:11 targets-host systemd[1]<EMAIL_ADDRESS>Consumed 824ms CPU time
Jul 17 13:41:11 targets-host systemd[1]<EMAIL_ADDRESS>Service RestartSec=100ms expired, scheduling restart.
Jul 17 13:41:11 targets-host systemd[1]<EMAIL_ADDRESS>Scheduled restart job, restart counter is at 4.
Jul 17 13:41:12 targets-host systemd[1]: Stopped Container 'target18'.
Jul 17 13:41:12 targets-host systemd[1]<EMAIL_ADDRESS>Consumed 824ms CPU time
Jul 17 13:41:12 targets-host systemd[1]: Starting Container 'target18'...
Jul 17 13:41:17 targets-host container target18[17081]: Spawning container target18 on /var/lib/containers/target18.

Jul 17 13:41:18 targets-host kernel: IPv6: ADDRCONF(NETDEV_UP): vb-target18: link is not ready
Jul 17 13:41:18 targets-host kernel: br0: port 12(vb-target18) entered blocking state
Jul 17 13:41:18 targets-host kernel: br0: port 12(vb-target18) entered disabled state
Jul 17 13:41:18 targets-host kernel: device vb-target18 entered promiscuous mode
Jul 17 13:41:18 targets-host kernel: br0: port 12(vb-target18) entered blocking state
Jul 17 13:41:18 targets-host kernel: br0: port 12(vb-target18) entered forwarding state
Jul 17 13:41:19 targets-host kernel: br0: port 12(vb-target18) entered disabled state
Jul 17 13:41:22 targets-host container target18[17081]: Failed to register machine: Machine 'target18' already exists
Jul 17 13:41:22 targets-host kernel: br0: port 12(vb-target18) entered disabled state
Jul 17 13:41:22 targets-host kernel: device vb-target18 left promiscuous mode
Jul 17 13:41:22 targets-host kernel: br0: port 12(vb-target18) entered disabled state
Jul 17 13:41:22 targets-host systemd[1]<EMAIL_ADDRESS>Main process exited, code=exited, status=1/FAILURE
Jul 17 13:41:22 targets-host systemd[1]<EMAIL_ADDRESS>Failed with result 'exit-code'.
Jul 17 13:41:22 targets-host systemd[1]: Failed to start Container 'target18'.
Jul 17 13:41:22 targets-host systemd[1]<EMAIL_ADDRESS>Consumed 812ms CPU time
Jul 17 13:41:22 targets-host systemd[1]<EMAIL_ADDRESS>Service RestartSec=100ms expired, scheduling restart.
Jul 17 13:41:22 targets-host systemd[1]<EMAIL_ADDRESS>Scheduled restart job, restart counter is at 5.
Jul 17 13:41:22 targets-host systemd[1]: Stopped Container 'target18'.
Jul 17 13:41:22 targets-host systemd[1]<EMAIL_ADDRESS>Consumed 812ms CPU time
Jul 17 13:41:22 targets-host systemd[1]: Starting Container 'target18'...
Jul 17 13:41:28 targets-host container target18[18360]: Spawning container target18 on /var/lib/containers/target18.
Jul 17 13:41:28 targets-host container target18[18360]: Press ^] three times within 1s to kill container.
Jul 17 13:41:28 targets-host kernel: IPv6: ADDRCONF(NETDEV_UP): vb-target18: link is not ready
Jul 17 13:41:28 targets-host kernel: br0: port 9(vb-target18) entered blocking state
Jul 17 13:41:28 targets-host kernel: br0: port 9(vb-target18) entered disabled state
Jul 17 13:41:28 targets-host kernel: device vb-target18 entered promiscuous mode
Jul 17 13:41:28 targets-host kernel: br0: port 9(vb-target18) entered blocking state
Jul 17 13:41:28 targets-host kernel: br0: port 9(vb-target18) entered forwarding state
Jul 17 13:41:29 targets-host kernel: br0: port 9(vb-target18) entered disabled state
Jul 17 13:41:32 targets-host container target18[18360]: Failed to register machine: Machine 'target18' already exists
...

then it's trapped in some loop. the same lines over and over again...
I see no reason for this. I think there are still limits present that needs to be raised. Hardware should be no problem since i have tested it on a 16 core Xeon and 48 GB RAM computer!
See the full syslog:
journal.log (25MB)
Steps to reproduce
Build ISO image and create bootable USB drive. You might need 25 GB RAM or a lot of SWAP!
Then just boot from the USB drive! (everything in ramdisk, computer will remain untouched)
https://gist.github.com/davidak/7d099b7ad4b23f144e4e8fed07e0d4f6
Technical details

system: "x86_64-linux"
host os: Linux 4.19.49, NixOS, 19.03.172866.4649b6ef4b5 (Koi)
multi-user?: yes
sandbox: yes
version: nix-env (Nix) 2.2.2
channels(root): "nixos-19.03.172979.8634c3b6199, nixos-hardware, nixos-unstable-19.09pre183392.83ba5afcc96"
nixpkgs: /nix/var/nix/profiles/per-user/root/channels/nixos

Workaround
Configure the containers to not autostart and start them manually, with some delay!
...
autoStart = false;

for i in $(nixos-container list); do nixos-container start $i && sleep 10; done
To fix this, we have to tell systemd to not overload the system while starting services (containers). I'm not sure how.

The configuration happens in https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/virtualisation/containers.nix
Any idea @arianvp @kampfschlaefer @grahamc?
Maybe upstream has a solution for that. We are not the only people using systemd-nspawn.

Hey @davidak,
100 identical containers seems a bit overkill to me. You will get a lot of processes that are just container boilerplate without any advantages. Normally containers are used for network-separation (thats why I use nixos/systemd containers), dependency-separation (the whole docker world is coming from that) or user-/customer-separation (which is the only reason I see for 100 identical containers). Gladly the dependency-separation scenario is being take care of in nixos already…
I have much less containers in use, but with more heavy 'payloads'. And when all are started at the same time, I get the same problems. I define dependencies between containers like this via systemd's after property. That is a loose coupling so when both containers are started at the same time, they start sequentially, but when one fails and is restarted, the other is not restarted (as opposed to depends afair).
Another way (what I want to explore 'when I have time'): With containers a lot of very similar boiler-plate processes are running just to get different PID-/user-/network-/filesystem-namespaces set up. I think the same can be reached by configuring these things for systemd units without the need of a systemd and journald and … inside the container.

@kampfschlaefer my usecase: my company develops a Vulnerability scanner, some customers have 55000 hosts to scan. i work in QA and want to build a test environment with as many targets (containers with some services and an IP) as possible with not so expensive hardware.
We scan only 10 targets at a time, so only 10 containers are really active. The others just idle. So i think when the host can handle 10 containers, it should be able to handle 100000 as well (from the cpu load).

I agree that this should work. I also think however that it's probably not a problem at our side; given that nixos-container is a thin wrapper around nspawn. Can you reproduce this bug with plain nspawn containers?

Can you reproduce this bug with plain nspawn containers?

That would be a huge effort to setup. In NixOS it's just a few lines :)
Since the problem is that systemd start too many things at the same time, they should provide a solution. It's maybe not nspawn related, just plain systemd unit config. I'm not an expert in that.

The workaround sounds not too complex to me, given it's quite an extreme situation IMHO.  (It could be some automatically executed script.)

@vcunat yes, we could just put a sleep in the container start script, but the time needed depends on the container. and since systemd knows when a container is ready, it should be able to coordinate it better. that should be a basic feature of systemd...
For my usecase, i could just execute that as a script at start.

I would start by trying to figure what exactly is failing. This is not apparent from the logs (the only things that jump out are Failed to install release agent and tee: /proc/self/fd/10: No such device or address). You may want to strace systemd-nspawn and its children.

tee: /proc/self/fd/10: No such device or address still appears with the workaround, so probably not the reason for the issue.
Same with Failed to install release agent, ignoring: No such file or directory.
When comparing the log of the failing system and the working one, most lines are identical. The relevant information seem to be:
systemd[1]<EMAIL_ADDRESS>Start operation timed out. Terminating.
After that, systemd starts to kill container processes!
...
container target18[]: [  OK  ] Started Networking Setup.
container target18[]:          Starting Extra networking commands....
container target18[]: [  OK  ] Started Extra networking commands..
systemd[1]<EMAIL_ADDRESS>Start operation timed out. Terminating.
container target18[]: [1.8K blob data]
container target18[]: [  OK  ] Stopped Name Service Cache Daemon.
container target18[]:          Starting Name Service Cache Daemon...
container target18[]: [515B blob data]
container target18[]: [  OK  ] Reached target Network.
container target18[]:          Starting Nginx Web Server...
container target18[]:          Starting Permit User Sessions...
container target18[]:          Starting Dnsmasq Daemon...
container target18[]: [  OK  ] Reached target Network is Online.
container target18[]: [  OK  ] Started Permit User Sessions.
container target18[]: [  OK  ] Started Console Getty.
container target18[]: [  OK  ] Reached target Login Prompts.
container target18[]: [2B blob data]
container target18[]: [1B blob data]
container target18[]: <<< Welcome to NixOS 19.03.172979.8634c3b6199 (x86_64) - console >>>
container target18[]: [1B blob data]
container target18[]: Run `nixos-help` for the NixOS manual.
container target18[]: [1B blob data]
systemd[1]<EMAIL_ADDRESS>State 'stop-sigterm' timed out. Killing.
systemd[1]<EMAIL_ADDRESS>Killing process  (systemd-nspawn) with signal SIGKILL.
systemd[1]<EMAIL_ADDRESS>Killing process 2816 (systemd) with signal SIGKILL.
systemd[1]<EMAIL_ADDRESS>Killing process 23579 (systemd-journal) with signal SIGKILL.
systemd[1]<EMAIL_ADDRESS>Killing process 31045 (dhcpcd) with signal SIGKILL.
systemd[1]<EMAIL_ADDRESS>Killing process 25020 (dbus-daemon) with signal SIGKILL.
systemd[1]<EMAIL_ADDRESS>Killing process 25659 (systemd-logind) with signal SIGKILL.
systemd[1]<EMAIL_ADDRESS>Killing process 32311 (nscd) with signal SIGKILL.
systemd[1]<EMAIL_ADDRESS>Killing process 3336 (nginx) with signal SIGKILL.
systemd[1]<EMAIL_ADDRESS>Killing process 3975 (nginx) with signal SIGKILL.
systemd[1]<EMAIL_ADDRESS>Killing process 2755 (dnsmasq) with signal SIGKILL.
systemd[1]<EMAIL_ADDRESS>Killing process 31530 (agetty) with signal SIGKILL.
container target18[]: target18 login:
systemd[1]<EMAIL_ADDRESS>Main process exited, code=killed, status=9/KILL
systemd[1]<EMAIL_ADDRESS>Killing process 2816 (systemd) with signal SIGKILL.
systemd[1]<EMAIL_ADDRESS>Killing process 31045 (dhcpcd) with signal SIGKILL.
systemd[1]<EMAIL_ADDRESS>Killing process 25020 (dbus-daemon) with signal SIGKILL.
systemd[1]<EMAIL_ADDRESS>Killing process 3975 (nginx) with signal SIGKILL.
systemd[1]<EMAIL_ADDRESS>Killing process 2755 (dnsmasq) with signal SIGKILL.
systemd[1]<EMAIL_ADDRESS>Killing process 31530 (agetty) with signal SIGKILL.
systemd[1]<EMAIL_ADDRESS>Failed with result 'timeout'.
systemd[1]: Failed to start Container 'target18'.

For comparison the log on the working system with workaround:
...
container target18[]: [  OK  ] Started Networking Setup.
container target18[]: [  OK  ] Started Journal Service.
container target18[]:          Starting Flush Journal to Persistent Storage...
container target18[]: [  OK  ] Reached target System Initialization.
container target18[]: [  OK  ] Started Daily Cleanup of Temporary Directories.
container target18[]: [  OK  ] Reached target Timers.
container target18[]: [  OK  ] Listening on SSH Socket.
container target18[]: [  OK  ] Listening on D-Bus System Message Bus Socket.
container target18[]: [  OK  ] Reached target Sockets.
container target18[]: [  OK  ] Reached target Basic System.
container target18[]:          Starting Extra networking commands....
container target18[]:          Starting Name Service Cache Daemon...
container target18[]:          Starting DHCP Client...
container target18[]: [  OK  ] Started Extra networking commands..
container target18[]: [  OK  ] Started Flush Journal to Persistent Storage.
container target18[]:          Starting Create Volatile Files and Directories...
container target18[]: [  OK  ] Started Create Volatile Files and Directories.
container target18[]: [  OK  ] Started D-Bus System Message Bus.
container target18[]: [  OK  ] Started Name Service Cache Daemon.
container target18[]: [  OK  ] Reached target Host and Network Name Lookups.
container target18[]: [  OK  ] Reached target User and Group Name Lookups.
container target18[]:          Starting Login Service...
container target18[]: [  OK  ] Started Login Service.
container target18[]: [381B blob data]
container target18[]: [  OK  ] Stopped Name Service Cache Daemon.
container target18[]:          Starting Name Service Cache Daemon...
container target18[]: [  OK  ] Started DHCP Client.
container target18[]: [  OK  ] Reached target Network.
container target18[]:          Starting Nginx Web Server...
container target18[]:          Starting Dnsmasq Daemon...
container target18[]:          Starting Permit User Sessions...
container target18[]: [  OK  ] Reached target Network is Online.
container target18[]: [  OK  ] Started Name Service Cache Daemon.
container target18[]: [  OK  ] Started Permit User Sessions.
container target18[]: [  OK  ] Started Console Getty.
container target18[]: [  OK  ] Reached target Login Prompts.
container target18[]: [  OK  ] Started Nginx Web Server.
container target18[]: [  OK  ] Started Dnsmasq Daemon.
container target18[]: [  OK  ] Reached target Multi-User System.
systemd[1]: Started Container 'target18'.
container target18[]: [2B blob data]
container target18[]: [1B blob data]
container target18[]: <<< Welcome to NixOS 19.03.172979.8634c3b6199 (x86_64) - console >>>
container target18[]: [1B blob data]
container target18[]: Run `nixos-help` for the NixOS manual.
container target18[]: [1B blob data]

I don't see anything helpful in strace output, but here it is: strace.txt

This looks like a solution: https://unix.stackexchange.com/a/445586
TimeoutStartSec is the default timeout for a systemd unit. It is 15 sec by default. (Maybe different global setting in NixOS?) If it is actually only 15 sec. for the container services, it don't surprises me that they are not able to start in that time.
I would set TimeoutStartSec to 60s for the container services.
I will test that and create a PR if there are no objections.

I tried TimeoutStartSec = "1min";, but it still fails.
It works with TimeoutStartSec = "10min";!
So it should be configurable, when even a very small container needs such a big value.
But i'm not sure if this is a reliable solution. The load was up to 216 at boot!
But the system was started in 6 minutes, with the workaround it took 27 minutes!
[root@targets-host:~]# systemd-analyze blame
    6min 33.401s<EMAIL_ADDRESS>    6min 32.637s<EMAIL_ADDRESS>    6min 32.246s<EMAIL_ADDRESS>    6min 31.710s<EMAIL_ADDRESS>    6min 31.183s<EMAIL_ADDRESS>    6min 31.088s<EMAIL_ADDRESS>    6min 17.311s<EMAIL_ADDRESS>    6min 15.803s<EMAIL_ADDRESS>    6min 14.843s<EMAIL_ADDRESS>    6min 14.391s<EMAIL_ADDRESS>    6min 13.263s<EMAIL_ADDRESS>    6min 12.078s<EMAIL_ADDRESS>    6min 12.044s<EMAIL_ADDRESS>    6min 10.918s<EMAIL_ADDRESS>    6min 10.196s<EMAIL_ADDRESS>     6min 9.849s<EMAIL_ADDRESS>

I wonder if setting StartupCPUWeight on the units will help. From man systemd.resource-control

       CPUWeight=weight, StartupCPUWeight=weight
           Assign the specified CPU time weight to the processes executed, if the unified control group hierarchy is used on the system.
           These options take an integer value and control the "cpu.weight" control group attribute. The allowed range is 1 to 10000.
           Defaults to 100. For details about this control group attribute, see cgroup-v2.txt[2] and sched-design-CFS.txt[4]. The
           available CPU time is split up among all units within one slice relative to their CPU time weight.

           While StartupCPUWeight= only applies to the startup phase of the system, CPUWeight= applies to normal runtime of the system,
           and if the former is not set also to the startup phase. Using StartupCPUWeight= allows prioritizing specific services at
           boot-up differently than during normal runtime.

           Implies "CPUAccounting=true".

           These settings replace CPUShares= and StartupCPUShares=.

I added StartupCPUWeight = 10, but the load was not lower. It got up to 262!
[root@targets-host:~]# systemd-analyze blame
    6min 40.747s<EMAIL_ADDRESS>    6min 39.893s<EMAIL_ADDRESS>    6min 39.781s<EMAIL_ADDRESS>    6min 39.551s<EMAIL_ADDRESS>    6min 39.027s<EMAIL_ADDRESS>    6min 38.992s<EMAIL_ADDRESS>    6min 38.884s<EMAIL_ADDRESS>    6min 38.214s<EMAIL_ADDRESS>

I have one more  idea. and I think this is also what the systemd people will tell you as an elegant solution to this problem.
nspawn-containers can be socket-activated. So you create 100 socket units, and the corresponding containers will be started on demand as soon as they receive traffic. this should spread out the startup a bit automatically if you're lucky and dont hit all the containers at the same time. (http://0pointer.de/blog/projects/socket-activated-containers.html)
of course, the service inside has to support socket activation too for this to work. which nginx doesn't. but there is a documented work around for that too: http://man7.org/linux/man-pages/man8/systemd-socket-proxyd.8.html

@arianvp sounds like an interesting feature for us to implement. Maybe create another issue.
For my usecase, it is better that the containers already run and don't have to start every time they are used.

That's not a requirement.  Actually it seems more usual to use the scheme that the service is only started once – when the first connection comes.


Various timeout parameter replaced with durations instead of ints

New Pull Request Checklist

[x] I have read the Documentation
[x] I have searched for a similar pull request in the project and found none
[x] I have updated this branch with the latest develop to avoid conflicts (via merge from master or rebase)
[ ] I have added the required tests to prove the fix/feature I am adding
[ ] I have updated the documentation (if necessary)
[x] I have run the tests and they pass

This merge request fixes / refers to the following issues: ...
Pull Request Description
Fixes #1375
This is a breaking change

Can you rebase on develop-5.0 please

Can you rebase on develop-5.0 please

Sure, will do.

@kuhnroyal It's now rebased. Some test still fail, I'll fix them later.

I looked at it some more. I believe we could remove receiveTimeout and sendTimeout because those to properties are just a concept of the library itself. Only the connectionTimeout is available on xhr requests and Darts HttpClient.
If we don't remove connectTimeout and sendTimeout, we could also make the underlying timeout equal to connectTimeout + sendTimeout + receiveTimeout.

Couple small nit-picks, otherwise ready to merge. Do you want to update the docs or should I?

By documentation, do you mean the readme and doc comments?

Yea

LGTM, thanks!
Can you rebase again to see if the checks are starting, I merged the adapted workflows into develop-5.0

Yeah, sure. Seems like it all still works 👍


Applying presets per buffer type

I'm trying to set a yellowish CursorLine color for terminal buffers using the following (naive?) config. When nvim starts, the CursorLine is blue as expected. The minute I open a terminal buffer, CursorLine will remain yellow for every window regardless of buftype in n mode (i works as expected). I've logged the output of skip and verified it returns the correct result each time. What am I doing wrong?
local nord_preset = {
	name = "nord",
	modes = {
		n = {
			winhl = {
				CursorLine = { bg = "#3a4355" },  -- default blueish cursorline
			},
		},
	},
}

local term_preset_high = {
	name = "term",
	priority = 100,
	skip = function()
		return vim.api.nvim_buf_get_option(0, "buftype") ~= "terminal"
	end,
	modes = {
		n = {
			winhl = {
				CursorLine = { bg = "#57593b" }, -- yellowish cursorline for terminal
			},
		},
	},
}

return {
	"rasulomaroff/reactive.nvim",
	opts = {
		builtin = {
			cursorline = true,
			cursor = true,
			modemsg = true,
		},
	},
	config = function(_, opts)
		local reactive = require("reactive")
		reactive.add_preset(nord_preset)
		reactive.add_preset(term_preset_high)
		reactive.setup(opts)
	end,
}

Hi there! Nothing wrong with your config! It's a bug and I found the reason. It's because reactive caches window-local highlights for hl groups and then reuses them if they're cached. I'll fix that and let you know! Thank you for reporting!

Hey @nkgm! Just fixed it. Can you check on your end as well? Thank you again for reporting!
I think I may add the ability to use a function for winhl and hl properties, so you'll be able to do the same (check buftype and return highlights) without creating 2 presets for this reason.

Hi @rasulomaroff, thanks for the quick fix, it's working great!

I think I may add the ability to use a function for winhl and hl properties, so you'll be able to do the same (check buftype and return highlights) without creating 2 presets for this reason.

That would be a fantastic improvement I'm personally looking forward to. As a new user I found the configuration a little overwhelming for the seemingly simple task of setting a few colors. I know this plugin does some pretty advanced stuff, so I'll have to revisit the docs, but simple things like, why can't I keep my whole config under opts? According to the docs one might use:
	opts = {
		builtin = {
			cursorline = true,
			cursor = true,
			modemsg = true,
		},
		configs = {
			nord = nord_preset,
			term = term_preset_high,
		},
	},

But examining more carefully (emphasis mine):

-- a key here is a preset name, a value can be a boolean (if false, presets will be disabled)
-- or a table that overwrites preset's values

So one still has to use add_preset, which feels a little counter-intuitive. At the same time I had to troubleshoot a conflict with the Nord plugin I was using at the time, causing CursorLine to disappear in n mode, now replaced with a modern Lua alternative. I'm not complaining, in fact my setup looks better than ever, and I'm happy I persevered.
These are just my observations as a new (and impatient) user, only meant as feedback. In fact, I really appreciate the effort you've invested not only into this plugin itself, but also writing extensive docs, so thanks again!

You raised a very interesting topic @nkgm! There's a huge difference between initialization and configuration for neovim plugins. You can read this article to understand what I'm talking about. I was developing this plugin keeping that idea in mind.
Briefly, any plugin should initialize itself and work without needing to call the setup function. reactive will initialize itself as soon as it will be required from anywhere in the code.
reactive was built with the idea of having several presets from other plugins, like your theme for example, and then allowing users to configure those presets through the setup function while also allowing users to create their own presets and loading them so it could operate both as a dependency and as a main module. This is why you have the priority field, ability to add several presets, name them, enabling if they are lazy etc. If you had everything in one place (setup function), then it would look really messy especially if you configured some presets from other plugins and added your own (maybe several ones?).
In your case it could be easier to put those presets in reactive/presets/{name}.lua and then load them in your config like that:
opts = {
	builtin = {
		cursor = true,
		cursorline = true,
		modemsg = true
	},
	load = { 'term', 'nord' } -- 'term' and 'nord' are for term.lua and nord.lua files
}

But it's up to you how you wanna configure it :)
Also, don't forget that reactive has from and to callbacks available for a mode configuration. Meaning that you can have separate presets for doing only functional stuff, like disabling relative numbers when going to insert mode and enabling when going from it. I know that it's not used for these purposes that often, but it can be.
I'm still in the process of searching the best way to do everything I've described. I think it's also worth it to create Wiki pages explaining how to do stuff, dos and don'ts etc. Thank you again!

I'm sorry for the lengthy response. Originally it consisted of two parts, but on second thought, the second part should be a standalone feature request issue about winhl accepting function values as discussed, along with an example setup outlining its importance, so I'll be opening a new issue for that. Here's the part relevant to the ongoing discussion.
I went through the article and I take it you are concerned about initialization order and side-effects? While I am not a Neovim plugin author and my knowledge is somewhat limited, I can't see what's stopping my (side-effects free) setup:
local preset1 = { ... }
local preset2 = { ... }

return {
  "rasulomaroff/reactive.nvim",
  opts = {
    builtin = {
      cursorline = true,
      cursor = true,
      modemsg = true,
    },
  },
  config = function(_, opts)
    local reactive = require("reactive")
    reactive.add_preset(preset1)
    reactive.add_preset(preset2)
    reactive.setup(opts)
  end,
}

... from becoming this (simpler) setup:
local preset1 = { ... }
local preset2 = { ... }

return {
  "rasulomaroff/reactive.nvim",
  opts = {
    builtin = {
      cursorline = true,
      cursor = true,
      modemsg = true,
    },
  },
  load = {
    preset1,  -- the tables created earlier
    preset2,
  }
  -- lazy will automatically do this for us
  -- config = function(_, opts)
  --   require("reactive").setup(opts)
  -- end,
}

load = { 'some_preset_file' } and load = { some_preset_table } should be equivalent, as long as some_preset_file is side-effects free. In the case that it's not, you could allow load to also accept function values:
local my_preset_table = ...

load = {
  'my_preset_file',
  my_preset_table,
  {
    name = 'my_inline_preset_table'
    ...
  },
  function()
    vim.api.nvim_launch_nuclear_warhead()
    return {
      name = 'my_side_effectful_preset_table',
      ...
    }
  end
}

then it would look really messy especially if you configured some presets from other plugins and added your own (maybe several ones?)

Agreed 100%. My argument was about also including a more intuitive way (as suggested just above) for the simpler "monolithic" setups, where splitting into multiple files would only get in the way, and add_preset wouldn't seem to add extra value. Having said that, add_preset gets the job done and I'm more than happy to keep using it now that I understand this plugin's configuration method a bit better. I'm only bringing it up is cause it tripped me when I was starting out.
Now, on to the feature request :)

@nkgm Sorry for the late response. My main concern wasn't about side-effects, but instead, it was about consistency.
For me, setup and any other function solve 2 different problems.
You need setup when you need to configure the way a plugin works or configure its extensions. In this plugin's case, 'extensions' are presets. For example in telescope there're also extensions and you can configure them in the setup function directly (like file search, grep etc).
But you don't need setup when you want to initialize a plugin or add some extensions to it. As I said, I consider a preset to be an extension of reactive, because basically what reactive does is watching mode/window changes and then perform some actions based on that. If there're presets, it will use them, otherwise just skip.
In the code that you suggested, where you put the whole preset into the load field, it would just create more confusion because:

There's add_preset method that is a part of reactive API, which allows you to add your own preset to the plugin.
There's load_preset method that is also a part of reactive API, which allows you to load your preset from a specified directory. It can be convenient when you have several presets.
And then there's a setup method with load field, which should tell a user that it operates the same way the original load_preset does, but within setup method.

I understand that the thing you suggested is a bit different, you want to have the same method as load, but for adding new presets, but here my concerns about it:

You used the setup method only because you used those built-in presets, because there's no other way to get those presets except calling this method.
Otherwise you could just use add_preset and be done

However, even though you used those built-in presets and they really fit your needs (what I really like), they exist just for demonstrating purposes and one's just encouraged to use their own ones. Since they're built-in, they can be just changed in the future, although I don't have any plans for that now. If you really like them, I would just suggest copy-pasting and adding those into your own preset. It will even increase performance, because instead of having 3 + 1 presets, you'll have only 1.
But if you do it (I mean copy-pasting), you can just use one add_preset or load_preset method and be done. No overhead with calling different methods etc, just one. And since you're not configuring anything, just adding your own preset, you don't need the setup method at all.
Hope this somehow explains what I was about :)