Handle Xvfb exiting immediately on spawn with 1 exit code #1113
Comments
brian-mann
added a commit
that referenced
this issue
Dec 25, 2017
…r when xvfb exits with status code 1, force tty in linux, handle colors in windows, enable logging cypress:xvfb stderr * cli: fixes #838 start cypress in dev by routing through the CLI - matches how we run in production better to keep parity and consistency * cli: add coerceFalse for clarity * cli: add global flag, update to work with windows * server: bring into parity with root scripts * cli: just execute start script directly to work with windows * cli: if colors are supported then force them via env vars - this fixes windows not displaying colors from electron because by default isTTY is false (due to electron) * cli: fixes #921 don't ignore stderr, inherit stdio on everything except when linux + xvfb - filter out stderr messages coming from Xlib or libudev (from xvfb) * cli, server: force stderr tty so that normalize tty behavior when piping * server: drop in supports color so debug outputs more colors! * server: remove empty line * root: refer to cypress not monorepo * cli: make util.supportsColor return boolean * cl: add tests around spawn behavior with forcing colors, tty, and stdio configuration * cli: handle xvfb onStderrData callback to output debug information * cli: handle non zero exit code error from xvfb with special message
|
Fixed by #1120. |
|
Released in |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I noticed today there is an edge case we specifically do not handle.
If Xvfb spawns and then immediately exits due to argument or permission errors, it will close with
1exit code. Due to the way we call into this, the CLI will just "hang" forever.This could be why some linux users have detected Cypress "hanging" initially on run without any output.
We need to update
@cypress/xvfb.The text was updated successfully, but these errors were encountered: