search

xonsh / xonsh

:shell: Python-powered shell. Full-featured and cross-platform.
http://xon.sh
Other
8.47k stars 643 forks source link

cat: stdin: Interrupted system call #2358

Closed brianmay closed 7 months ago

brianmay commented 7 years ago

The following happens every time I run cat. This is on OSX - IIRC I have seen the same on Debian/Stretch (but don't have a box handy right now to test).

$cat
cat: stdin: Interrupted system call

Possibly related to #2160, not sure.

gforsyth commented 7 years ago

Hi @brianmay -- thanks for reporting! I can't reproduce this on Arch. Could you post the output of xonfig please?

brianmay commented 7 years ago

Sorry, maybe I lie - I can't see this on Debian/stretch right now. Will move over to my OSX laptop, where I know I can reproduce this.

brianmay commented 7 years ago

On OSX:

+------------------+----------------------+
| xonsh            | 0.5.9                |
| Git SHA          | 2ae5218              |
| Commit Date      | Mar 15 12:06:26 2017 |
| Python           | 3.6.1                |
| PLY              | 3.9                  |
| have readline    | True                 |
| prompt toolkit   | None                 |
| shell type       | readline             |
| pygments         | 2.2.0                |
| on posix         | True                 |
| on linux         | False                |
| on darwin        | True                 |
| on windows       | False                |
| on cygwin        | False                |
| is superuser     | False                |
| default encoding | utf-8                |
| xonsh encoding   | utf-8                |
| encoding errors  | surrogateescape      |
+------------------+----------------------+
mitnk commented 7 years ago

I can reproduce this issue on Mac. Haven't dig into it.

mitnk commented 7 years ago

This is a PopenThread related issue too. Mark cat with unthreadable can solve this issue.

Details: When a progress try to access STDIN/STDOUT, it should have the controlling terminal, on mac (at least) the "give-terminal-to-cat" is happening on xonsh main thread, while the "cat" process is spawned at a second thread. When cat starts to run(), the job of "give-terminal-to-cat" in main thread may not done, and it try to access STDIN, which causes the error: cat: stdin: Interrupted system call. (On Mac, I can get functional $ cat run with PopenThread in rare cases with most (over 90%) cases failed).

gforsyth commented 7 years ago

Hi @brianmay -- can you confirm that @mitnk's proposed fix will work on your end?

If you run 

__xonsh_commands_cache__.threadable_predictors['cat'] = lambda args: False

in your session, does cat work?

ghost commented 7 years ago

marking cat as unthreadable makes no sense to me. what if we turn this around, spawn cat on main thread and manage reading from the second thread. i am sure ppl thought of this before, just throwing ideas.

brianmay commented 7 years ago

@gforsyth Yes, that command does work.

I have no opinion (yet) on the best solution however.

brianmay commented 7 years ago

Still not sure I understand this issue.

... while the "cat" process is spawned at a second thread ...

Doesn't invoking cat fork a separate process? It looks like an external command to me, not a built in.

mitnk commented 7 years ago

In current xonsh, cat (the bare $ car cmd) is not directly forked, xonsh fork it within a separated thread. see PopenThread class for details is you want to.

mitnk commented 7 years ago

A __xonsh_commands_cache__.threadable_predictors['cat'] = lambda args: False is a temporary solution if you need $ cat (or other commands that needs to enter alternative mode) to work. We hope xonsh can fix these issue in a better way in future.

gforsyth commented 7 years ago

@brianmay or @mitnk -- question: does cat error out even when you are cating a file? Or just when asking for stdin?

gforsyth commented 7 years ago

And since platform-specific threadable stuff sounds nightmare-ish, maybe we can do a workaround on this by adding a python-based cat replacement to xoreutils?

gforsyth commented 7 years ago

Oh wait... we did that already. Hey @brianmay, how does cat behave if you do a xontrib load xoreutils?

gforsyth commented 7 years ago

apologies, that's xontrib load coreutils

mitnk commented 7 years ago

cat a file has no issues.

gforsyth commented 7 years ago

Is there actually a use case for a bare cat? I mean, we want to eliminate bugs, generally, but in terms of priorities, is this error holding anyone back from anything?

brianmay commented 7 years ago

I had problems with coreutils, so removed it. Will try again and - assuming I still have problems - report in another bug report.

brianmay commented 7 years ago

For problems with coreutils see #2365.

I have no immediate reason for requiring cat from stdin to work, however it concerns me that other tools might have similar issues.

I have also seen similar issues with grep. Yet again though, I can't think of a use case where you would need to use grep from stdin.

Why doesn't this affect all programs that read from stdin?

ghost commented 7 years ago

@gforsyth yea there are some use cases for bare cat, but even if there isn't any, it's cats expected behavior, so we should not dismiss it because xonsh can't handle it yet.

gforsyth commented 7 years ago

Hey @laerus -- totally agree, just want to figure out if this is causing serious headaches immediately for people or if it's something to go on a more long term to-fix list. Also, can anyone replicate this on Linux? I wonder if this is one of OSX's rewrites causing headaches.

@brianmay -- just out of curiosity, not as a solid workaround, is it possible to install gnu cat from homebrew? Does that still have this issue?

ghost commented 7 years ago

@gforsyth cannot reproduce this on debian-testing, cat works in xonsh exactly as it works in bash.

brianmay commented 7 years ago

GNU Cat works. Why does GNU Cat work but the built in doesn't? Is this the case of the built in one doing something dodgy?

gforsyth commented 7 years ago

A bunch of the OSX built-ins are rewrites to get around the GPL and they often behave slightly differently in corner-cases.

tekacs commented 7 years ago

It's unclear whether to put this here or in #2160, but I'm experiencing this when using cat <somefile> (no reliance on stdin).

@scopatz asked for an asciinema in #2160, so I've made one for this:

https://asciinema.org/a/c8jjrp4Q4r7nmFxzQw9EwAe4P

I should add that the issue is repeatable, so if I continue to run this cat command a bunch more times, after half a dozen repeats I get the same behaviour as above.

This doesn't happen in any other shell, but it's worth nothing that this happens on a 9p (it's a QEMU mount) filesystem and doesn't happen on the ext4 home partition.

Could it be that this only happens for 'slow' system calls, or 'slow' input streams (or some variant of this), perhaps?

I also ran into this issue with ruby, when running an (old) Heroku toolbelt command, again in the same directory (same behaviour as above - I ran the command and it immediately terminated with ruby: Interrupted system call).

Here is my xonfig:

+------------------+-----------------+
| xonsh            | 0.5.10          |
| Python           | 3.6.2           |
| PLY              | 3.9             |
| have readline    | True            |
| prompt toolkit   | 1.0.14          |
| shell type       | prompt_toolkit  |
| pygments         | 2.2.0           |
| on posix         | True            |
| on linux         | True            |
| distro           | arch            |
| on darwin        | False           |
| on windows       | False           |
| on cygwin        | False           |
| is superuser     | False           |
| default encoding | utf-8           |
| xonsh encoding   | utf-8           |
| encoding errors  | surrogateescape |
+------------------+-----------------+
jaraco commented 6 years ago

This issue has gotten more severe for me lately. I recently updated to xonsh 0.7.9 and where before the issue would happen about 50% of the time, now it seems to be happening much more often, like 90% of the time. Not sure if that provides any insight into the issue. There may be other factors at play (upgrade of OS, apps running in background, etc), so take this with a grain of salt.

scopatz commented 6 years ago

@jaraco - what is your xonfig say?

jaraco commented 6 years ago 
~ $ xonfig
+------------------+----------------------+
| xonsh            | 0.8.2                |
| Git SHA          | 78b13924             |
| Commit Date      | Oct 29 14:16:50 2018 |
| Python           | 3.7.1                |
| PLY              | 3.9                  |
| have readline    | True                 |
| prompt toolkit   | 2.0.4                |
| shell type       | prompt_toolkit2      |
| pygments         | None                 |
| on posix         | True                 |
| on linux         | False                |
| on darwin        | True                 |
| on windows       | False                |
| on cygwin        | False                |
| on msys2         | False                |
| is superuser     | False                |
| default encoding | utf-8                |
| xonsh encoding   | utf-8                |
| encoding errors  | surrogateescape      |
+------------------+----------------------+
jaraco commented 6 years ago

And then I upgraded to xonsh 0.8.3 and tested again. Right now, it fails about 2/3 of the time:

draft $ cat > foo.py
cat: stdin: Interrupted system call
draft $ cat > foo.py
cat: stdin: Interrupted system call
draft $ cat > foo.py
draft $ cat > foo.py
cat: stdin: Interrupted system call
draft $ cat > foo.py
cat: stdin: Interrupted system call
draft $ cat > foo.py
draft $ cat > foo.py
cat: stdin: Interrupted system call
draft $ cat > foo.py
cat: stdin: Interrupted system call
draft $ cat > foo.py
cat: stdin: Interrupted system call
draft $ cat > foo.py
draft $ cat > foo.py
cat: stdin: Interrupted system call
scopatz commented 5 years ago

Hmmm I am really unsure of what is going on here.

jaraco commented 4 years ago

This issue has gone away for me for a long time (months). Today it happened once, reminding me to check the status of this. If the frequency of this issue has been reduced to just once in a blue moon, it's ignoreable (for me). I'll report back if I find it's more frequent than that.

anki-code commented 3 years ago

I also can't reproduce this and I'm going to close this issue.

jaraco commented 3 years ago

This issue has started affecting my environment again. It's almost 100% now.

$ xonfig
+------------------+----------------------+
| xonsh            | 0.10.1               |
| Git SHA          | e9b12c8b             |
| Commit Date      | Jul 24 22:47:37 2021 |
| Python           | 3.10.0               |
| PLY              | 3.11                 |
| have readline    | True                 |
| prompt toolkit   | 3.0.19               |
| shell type       | prompt_toolkit       |
| history backend  | json                 |
| pygments         | None                 |
| on posix         | True                 |
| on linux         | False                |
| on darwin        | True                 |
| on windows       | False                |
| on cygwin        | False                |
| on msys2         | False                |
| is superuser     | False                |
| default encoding | utf-8                |
| xonsh encoding   | utf-8                |
| encoding errors  | surrogateescape      |
| on jupyter       | False                |
| jupyter kernel   | None                 |
| xontrib 1        | vox                  |
| xontrib 2        | voxapi               |
+------------------+----------------------+
$ cat > changelog.d/2765.patch.rst
cat: stdin: Interrupted system call
$ cat > changelog.d/2765.patch.rst
cat: stdin: Interrupted system call
$ cat > changelog.d/2765.patch.rst
cat: stdin: Interrupted system call
$ cat > changelog.d/2765.patch.rst
cat: stdin: Interrupted system call
$ cat > changelog.d/2765.patch.rst
cat: stdin: Interrupted system call
$ cat > changelog.d/2765.patch.rst
cat: stdin: Interrupted system call
$ cat > changelog.d/2765.patch.rst
cat: stdin: Interrupted system call
$ cat > changelog.d/2765.patch.rst
cat: stdin: Interrupted system call
$ cat > changelog.d/2765.patch.rst
cat: stdin: Interrupted system call
$ cat > changelog.d/2765.patch.rst
cat: stdin: Interrupted system call
$ cat > changelog.d/2765.patch.rst
cat: stdin: Interrupted system call
$ cat > changelog.d/2765.patch.rst
cat: stdin: Interrupted system call
$ cat > changelog.d/2765.patch.rst
cat: stdin: Interrupted system call
anki-code commented 3 years ago

Hi @jaraco! Please try to repeat on xonsh 0.11.

jaraco commented 3 years ago

It's still happening for me:

~ $ cd draft
draft $ cat > foo
cat: stdin: Interrupted system call
draft $ xonsh --version
xonsh/0.11.0
draft $ cat > foo
cat: stdin: Interrupted system call
draft $ cat > foo
cat: stdin: Interrupted system call
draft $ cat > foo
it worked this time
xonfig ``` +------------------+------------------------+ | xonsh | 0.11.0 | | Git SHA | 337cf25a | | Commit Date | Nov 17 15:37:41 2021 | | Python | 3.10.0 | | PLY | 3.11 | | have readline | True | | prompt toolkit | 3.0.19 | | shell type | prompt_toolkit | | history backend | json | | pygments | None | | on posix | True | | on linux | False | | on darwin | True | | on windows | False | | on cygwin | False | | on msys2 | False | | is superuser | False | | default encoding | utf-8 | | xonsh encoding | utf-8 | | encoding errors | surrogateescape | | on jupyter | False | | jupyter kernel | None | | xontrib 1 | vox | | xontrib 2 | voxapi | | RC file 1 | /Users/jaraco/.xonshrc | +------------------+------------------------+ ```
anki-code commented 3 years ago

@jaraco weird. What if you run it in xonsh --no-rc?

jaraco commented 3 years ago

Running with --no-rc causes two changes:

draft $ xonsh --no-rc
/Users/jaraco/.local/pipx/venvs/xonsh/lib/python3.10/site-packages/prompt_toolkit/application/application.py:882: DeprecationWarning: There is no current event loop
  loop = get_event_loop()
jaraco@Karui-Tatchi ~/draft $ cat > foo
cat: stdin: Interrupted system call
/Users/jaraco/.local/pipx/venvs/xonsh/lib/python3.10/site-packages/prompt_toolkit/application/application.py:882: DeprecationWarning: There is no current event loop
  loop = get_event_loop()
jaraco@Karui-Tatchi ~/draft $ cat > foo
/Users/jaraco/.local/pipx/venvs/xonsh/lib/python3.10/site-packages/prompt_toolkit/application/application.py:882: DeprecationWarning: There is no current event loop
  loop = get_event_loop()
jaraco@Karui-Tatchi ~/draft $ cat > foo
/Users/jaraco/.local/pipx/venvs/xonsh/lib/python3.10/site-packages/prompt_toolkit/application/application.py:882: DeprecationWarning: There is no current event loop
  loop = get_event_loop()
jaraco@Karui-Tatchi ~/draft $ cat > foo
/Users/jaraco/.local/pipx/venvs/xonsh/lib/python3.10/site-packages/prompt_toolkit/application/application.py:882: DeprecationWarning: There is no current event loop
  loop = get_event_loop()
jaraco@Karui-Tatchi ~/draft $ cat > foo
cat: stdin: Interrupted system call
/Users/jaraco/.local/pipx/venvs/xonsh/lib/python3.10/site-packages/prompt_toolkit/application/application.py:882: DeprecationWarning: There is no current event loop
  loop = get_event_loop()

First, running with --no-rc causes this "no current event loop" warning. That happens even when I launch xonsh directly (and not within xonsh). I've seen that warning before occasionally, but the warning comes up reliably with --no-rc.

The other difference is that, although the error occurs, it seems to be occurring less frequently. ~50% gets the "interrupted system call" message.

yaxollum commented 2 years ago

This issue might be caused by the same problem as https://github.com/xonsh/xonsh/issues/4034#issuecomment-1207513794

EDIT: actually, I don't think it's the exact same problem because I was still able to reproduce this issue after testing out my fix to #4034

yaxollum commented 2 years ago

By the way, I'm also able to reproduce it by running cat on macOS using tmate

anki-code commented 7 months ago

I can't reproduce this on current master on macOS. I tried many times:

cat > foo
# ^C