Matt Heon

That all sounds correct. Of these: * Backwards compatibility is tricky, but likely not particularly difficult - just need to figure out a good way of identifying if iptables is...

Assuming the sig-proxy flag is set to true (the default), we should be forwarding that SIGHUP into the container when Podman receives it. As such, it's really down to what...

Per the docs: `Proxy received signals to the container process (non-TTY mode only). SIGCHLD, SIGSTOP, and SIGKILL are not proxied.` Which is actually incorrect - we definitely proxy in TTY...

I see no evidence that this is a general issue. Podman correctly forwards signals via `--sig-proxy`, which will result in application termination on terminal close (assuming the application properly responds...

It's more accurate to say that we can't make them *not* terminate when the container exits. The kernel enforces the rule that any PID namespace will kill every process in...

@Luap99 Don't know if that works. Conmon dying is only going to take out the first PID the exec session started; anything else it did, probably just reparents on top...

As long as the DB lives on a tmpfs, sure - that'll wipe the DB on reboot. If you need something even less persistent than that, you can close your...

Hmmm. So in that case, you'd want to detect reboots, and then "unlock" all the locks? Libpod does something similar (detect a reboot via a file in tmpfs disappearing, and...

@nalind PTAL - this one seems pretty bad, given that c/storage seems unusable? I don't think this is Podman itself given that we don't make any changes to c/storage paths...

Error's coming out of c/common image library, but I suspect it's hiding a real error from c/storage. @vrothberg PTAL