toolbox run does not work when no tty is attached

[tosmi]

the current implementation of run() always uses the flags --interactive and --tty for podman exec. i'm using toolbox run mostly from dmenu, so there is no tty attached. Maybe --tty and --interactive should only be used when enterning a container.

will create a pull request asap.

thanks
toni

[debarshiray]

You need --interactive --tty in toolbox run if you want to run a terminal text editor, for example. Maybe toolbox run should grow a flag for this?

[tosmi]

yep maybe. i'll try to come up with something next week. didn't find the time for anything the last week...
i mostly use toolbox run to start my containerized apps within X11 (e.g. vlc, firefox, emacs...).

i suppose the default should be to use a tty and optionally disable allocating a tty, so --no-tty?

thanks
toni

[tosmi]

so #179 should fix this and works for me.

thanks
toni

[ibotty]

Any reason why this is not acted upon? Should it be determined whether there actually is a tty and automatically disable interactive and tty forward?

[tosmi]

it would be great if this could be merged

thanks

[HarryMichal]

Hey @tosmi! I just added your PR (#179) in the rewritten version of Toolbox (tracked here: #318). I just adjusted it to the Go code. Thank you for your contribution and I apologize for not merging this sooner!

[jmou]

Hi! I came looking for a similar issue but I think the problem is a little more general. In particular I think there are broadly 3 use cases for toolbox run:

• Running GUI (non-terminal) applications, possibly without a controlling tty. This is @tosmi 's use case. We SHOULD NOT allocate a tty in this case.
• Running interactive terminal applications that need a tty (bash, screen, vim, anything curses). We SHOULD allocate a tty in this case.
• Running non-interactive terminal applications. These may be used with stdin often attached to a pipe (netcat), which does not work with a tty. We SHOULD NOT allocate a tty in this case.

An app like ssh may be either the second (if invoked without a command, it allocates a tty) or the third (does not allocate a tty if invoked with a command).

I think a simple heuristic would work in the vast majority of situations. If stdin is attached to a tty, then we can allocate a tty; if stdin is not attached to a tty, then do not allocate a tty. I think this handles all of the above use cases. We might allocate a tty when it's not strictly necessary, but we should never allocate a tty when it would break (no controlling terminal or stdin redirected).

This is a simple script I put together to run netcat:

#!/bin/sh
[ -t 0 ] && ttyflag=-t
exec podman exec -i $ttyflag fedora-toolbox-32 nc "$@"  

Let me know if I can help with this, I can probably put together a PR.

[jmou]

BTW I just had a quick glance at https://github.com/containers/toolbox/pull/179 and saw that --notty there is also used to unset --interactive. I think this is not desirable because it breaks the third use case, and it is not necessary for the original issue (not setting --tty is sufficient).

[e-user]

@HarryMichal What happened to the changeset from #179? #318 was merged and master is now based on Go, but the notty flag is missing. I need this exact feature for several use cases.

[tosmi]

thanks @e-user. i have the same issue with the go version. still using my forked versioin for -notty support.

[e-user]

FWIW if anyone else is also still having this problem, I'm using a script toolbox-wrapper that I'm symlinking the respective command to: https://gist.github.com/e-user/d75db5a891bbb0593e9252ee5c8e0826

E.g. pointing gcloud at toolbox-wrapper means gcloud will be run from the toolbox, instead. The script also supports piping from stdin and starts the toolbox if it's not already running.

[jmou]

I wrote almost the same script for myself! It also allocates a TTY if stdin is a terminal which helps with some interactive commands. https://gist.github.com/jmou/55111caa23d9aeb777ff70c89b9ceffb

[e-user]

@HarryMichal can you please re-open this ticket? It was never fixed.

[HarryMichal]

@debarshiray I think we should revisit this. There's also the issue with text outputted by toolbox run that adds CRLF to the of every line (there's a Podman issue about this). Because of the issue we also need to use a small workaround in our system tests.

What approach would be more desirable? An explicit flag for setting/unsetting the --tty option in podman exec or having a heuristic as @jmou suggests? Or maybe both to give the option to override the heuristic?