start: do not unconditionally dup std{in,out,err}

start: do not unconditionally dup std{in,out,err}

Starting with commit

    commit c5b93afba1d79c6861a6f45db2943b6f3cfbdab4
    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>