============================
SRU Justification
Impact: callers of lxc-start can have confusing failures to start
Development fix: always close all fds
Stable fix: same as development fix
Test case:
1. lxc-create -t ubuntu -n p1
2. cat > execme.c << EOF
#include <stdio.h>
#include <unistd.h>
int main()
{
FILE *f = fopen("/tmp/ab", "w");
//int ret = execl("/usr/bin/lxc-start", "/usr/bin/lxc-start", "-d", "-n", "p1", NULL);
int ret = execl("/usr/bin/lxc-start", "/usr/bin/lxc-start", "-n", "p1", NULL);
printf("should not be here (ret %d)\n", ret);
}
EOF
3. make execme
4. sudo ./execme
Without this patch, the container will fail to start with an error message
saying an fd was inherited. With the patch, the container will start (and
the fd will have been closed)
Regression potential: if anyone was counting on lxc-start to fail when started
with open fds, that will no longer happen.
============================
Since the lxc-start command quits with an error if any inherited FDs are not disconnected, why is it necessary to specify --close-all-fds at all?
(I just spent an hour debugging a situation where some FDs were falling through from parent processes only in the remote deployment configuration...)
In quantal the default is now to not fail on inherited fds.
In precise, the default is still to fail. Since it sends a warning debug
message, I'm not sure that changing this behavior in an SRU is warranted.
Not that I can think of any case where changing the behavior would cause
a regression.