Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
start: do not unconditionally dup std{in,out,err}
Starting with commit commit c5b93af Author: Li Feng <lifeng68@huawei.com> Date: Mon Jul 10 17:19:52 2017 +0800 start: dup std{in,out,err} to pty slave In the case the container has a console with a valid slave pty file descriptor we duplicate std{in,out,err} to the slave file descriptor so console logging works correctly. When the container does not have a valid slave pty file descriptor for its console and is started daemonized we should dup to /dev/null. Closes #1646. Signed-off-by: Li Feng <lifeng68@huawei.com> Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com> we made std{err,in,out} a duplicate of the slave file descriptor of the console if it existed. This meant we also duplicated all of them when we executed application containers in the foreground even if some std{err,in,out} file descriptor did not refer to a {p,t}ty. This blocked use cases such as: echo foo | lxc-execute -n -- cat which are very valid and common with application containers but less common with system containers where we don't have to care about this. So my suggestion is to unconditionally duplicate std{err,in,out} to the console file descriptor if we are either running daemonized - this ensures that daemonized application containers with a single bash shell keep on working - or when we are not running an application container. In other cases we only duplicate those file descriptors that actually refer to a {p,t}ty. This logic is similar to what we do for lxc-attach already. Refers to #1690. Closes #2028. Reported-by: Felix Abecassis <fabecassis@nvidia.com> Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
- Loading branch information