stdin reading under nohup goes kablooey

[kingkisskill]

run git project : flask-restplus-server-example on linux(centos7), example

invoke app.run --flask-config development success run
invoke app.run --flask-config development & success run
nohup invoke app.run --flask-config development & failed run and error in nohup.out

Requirement already satisfied: pycparser in /usr/local/lib/python3.7/site-packages (from cffi>=1.1->bcrypt<4,>=3.1.3->-r app/requirements.txt (line 19)) (2.19)
Traceback (most recent call last):
File "/usr/local/bin/invoke", line 10, in
sys.exit(program.run())
File "/usr/local/lib/python3.7/site-packages/invoke/program.py", line 384, in run
self.execute()
File "/usr/local/lib/python3.7/site-packages/invoke/program.py", line 566, in execute
executor.execute(*self.tasks)
File "/usr/local/lib/python3.7/site-packages/invoke/executor.py", line 129, in execute
result = call.task(*args, **call.kwargs)
File "/usr/local/lib/python3.7/site-packages/invoke/tasks.py", line 127, in call
result = self.body(*args, **kwargs)
File "/opt/flask-restplus-server-example/tasks/app/run.py", line 40, in run
context.invoke_execute(context, 'app.dependencies.install')
File "/opt/flask-restplus-server-example/tasks/init.py", line 73, in invoke_execute
results = Executor(namespace, config=context.config).execute((command_name, kwargs))
File "/usr/local/lib/python3.7/site-packages/invoke/executor.py", line 129, in execute
result = call.task(*args, **call.kwargs)
File "/usr/local/lib/python3.7/site-packages/invoke/tasks.py", line 127, in call
result = self.body(*args, **kwargs)
File "/opt/flask-restplus-server-example/tasks/app/dependencies.py", line 102, in install
install_python_dependencies(context)
File "/usr/local/lib/python3.7/site-packages/invoke/tasks.py", line 127, in call
result = self.body(*args, **kwargs)
File "/opt/flask-restplus-server-example/tasks/app/dependencies.py", line 27, in install_python_dependencies
context.run("pip install -r requirements.txt %s" % ('--upgrade' if force else ''))
File "/usr/local/lib/python3.7/site-packages/invoke/context.py", line 94, in run
return self._run(runner, command, **kwargs)
File "/usr/local/lib/python3.7/site-packages/invoke/context.py", line 101, in _run
return runner.run(command, **kwargs)
File "/usr/local/lib/python3.7/site-packages/invoke/runners.py", line 291, in run
return self._run_body(command, **kwargs)
File "/usr/local/lib/python3.7/site-packages/invoke/runners.py", line 399, in _run_body
raise ThreadException(thread_exceptions)
invoke.exceptions.ThreadException:
Saw 1 exceptions within threads (OSError):

Thread args: {'kwargs': {'echo': None,
'input_': <_io.TextIOWrapper name='' mode='r' encoding='UTF-8'>,
'output': <_io.TextIOWrapper name='' mode='w' encoding='UTF-8'>},
'target': <bound method Runner.handle_stdin of <invoke.runners.Local object at 0x7ff985552160>>}

Traceback (most recent call last):

File "/usr/local/lib/python3.7/site-packages/invoke/util.py", line 233, in run
super(ExceptionHandlingThread, self).run()

File "/usr/local/lib/python3.7/threading.py", line 865, in run
self._target(*self._args, **self._kwargs)

File "/usr/local/lib/python3.7/site-packages/invoke/runners.py", line 687, in handle_stdin
data = self.read_our_stdin(input_)

File "/usr/local/lib/python3.7/site-packages/invoke/runners.py", line 646, in read_our_stdin
bytes_ = input_.read(bytes_to_read(input_))

OSError: [Errno 9] Bad file descriptor

[bitprophet]

Ran into this with a $DAYJOB user (technically via Paramiko's use of Invoke for ProxyCommand, but that should be irrelevant).

Nohup is very rude here, it literally turns stdin into a normal file descriptor but to an unreadable file. So we cannot actually tell until we try reading, that it's going to explode like this. I don't see another solve besides trapping and ignoring EBADF in particular (as a flavor of OSError).

It'll be limited to exactly this spot (reading stdin) so I expect fallout to be minimal: the only obvious case where this would be highly confusing, is where a user was both expecting to read useful data from stdin, and stdin somehow got really badly broken in a way yielding EBADF (eg perhaps redirecting a network-hosted file to stdin, and that network mount getting broken in the interim). In such a case they'd arguably want this OSError to show up, and now it'll silently vanish.

[bitprophet]

Fix committed to 1.7 and main branches, will be released next cycle. EDIT: nah that's a bad habit. 1.7.1 is out with this as the sole contents 👍🏻