New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

JRuby + Cygwin + Jenkins causes message related to stty #3989

Closed
rovf opened this Issue Jul 1, 2016 · 9 comments

Comments

Projects
None yet
3 participants
@rovf

rovf commented Jul 1, 2016

Environment

jruby 1.7.25 (1.9.3p551) 2016-04-13 867cb81 on Java HotSpot(TM) 64-Bit Server VM 1.8.0_31-b13 +jit [Windows 7-amd64]

Expected Behavior

  • Ruby should not print warnings related to tty when running on Windows

Actual Behavior

When I run JRuby on Jenkins, but invoked from a Cygwin shell, I get the annoying warning message

stty: standard input: Inappropriate ioctl for device

This does not happen when I run JRuby from a (Cygwin-) command line (interactively), or on Jenkins from a Windows command line.

I remember that there was a very similar error in jruby 1.7.23, where a stty warning was always shown when executing jruby from a Cygwin shell script, even with an interactive one. This error had been fixed in 1.7.24.

Running the script as a Jenkins job means that there is no console associated to the job. Perhaps the bugfix mentioned, did not pay attention to this possibility.

Thomas Enebo commented to this in the JRuby mailing list in the following way: "The gist of things is when you run via cygwin on Jenkins it is from a daemon and it has no tty associated with it. When we run stty you get this error. When you run from a cygwin windows it does have a tty so stty completes without issue."

@enebo enebo added this to the JRuby 1.7.26 milestone Jul 1, 2016

@enebo enebo added the windows label Jul 1, 2016

@enebo

This comment has been minimized.

Show comment
Hide comment
@enebo

enebo Jul 1, 2016

Member

I marked this as Windows but it could be any platform where we fall back to calling 'stty' in io/console.rb from a daemon which has no console.

Member

enebo commented Jul 1, 2016

I marked this as Windows but it could be any platform where we fall back to calling 'stty' in io/console.rb from a daemon which has no console.

@enebo

This comment has been minimized.

Show comment
Hide comment
@enebo

enebo Jul 1, 2016

Member

This does beg a question though...why does io/console.rb get loaded when it is not run on a tty?

Member

enebo commented Jul 1, 2016

This does beg a question though...why does io/console.rb get loaded when it is not run on a tty?

@headius

This comment has been minimized.

Show comment
Hide comment
@headius

headius Aug 24, 2016

Member

@rovf How much output are we talking about here? If this is a one-time warning it's not a big deal.

We could also silence stty by being a bit trickier with our spawning, so that if it has stderr warnings we don't see them.

And @enebo's question is valid too...ideally we wouldn't be hitting console for non-tty. That would indicate we're not properly detecting that there's no tty.

Can you track down where exactly this is happening? I suspect it's in io/console.rb.

Member

headius commented Aug 24, 2016

@rovf How much output are we talking about here? If this is a one-time warning it's not a big deal.

We could also silence stty by being a bit trickier with our spawning, so that if it has stderr warnings we don't see them.

And @enebo's question is valid too...ideally we wouldn't be hitting console for non-tty. That would indicate we're not properly detecting that there's no tty.

Can you track down where exactly this is happening? I suspect it's in io/console.rb.

@rovf

This comment has been minimized.

Show comment
Hide comment
@rovf

rovf Aug 25, 2016

From the viewpoint of functionality, if it is just a warning, it really is not a big deal. However, if you have - as in my case - a system consisting of plenty of (Zsh-)shell scripts, each calling lots of JRuby programs, seeing all the warnings looks confusing and is not something I would like to hand over to my customer as professional work from my side - my customer might argue that I'm using a programming language implementation which is not done in a good way. Since I not only want to get "my work done" somehow, but also demonstrate the pros of JRuby, I certainly want to avoid this warning to pop up.

A solution which I could do for myself, would be to write a wrapper script around JRuby, which catches STDERR and filters out exactly this warning, but since I'm likely not the only person seeing this warning, If it is difficult to fix the root cause, would it be possible to disable this warning by a command line switch? Kind of: --no-warning=stty; ... or maybe a switch to disable stty: --nostty. If I could control this by an environment variable too, it would be even more convenient (kind of: JRUBY_OPTIONS)

rovf commented Aug 25, 2016

From the viewpoint of functionality, if it is just a warning, it really is not a big deal. However, if you have - as in my case - a system consisting of plenty of (Zsh-)shell scripts, each calling lots of JRuby programs, seeing all the warnings looks confusing and is not something I would like to hand over to my customer as professional work from my side - my customer might argue that I'm using a programming language implementation which is not done in a good way. Since I not only want to get "my work done" somehow, but also demonstrate the pros of JRuby, I certainly want to avoid this warning to pop up.

A solution which I could do for myself, would be to write a wrapper script around JRuby, which catches STDERR and filters out exactly this warning, but since I'm likely not the only person seeing this warning, If it is difficult to fix the root cause, would it be possible to disable this warning by a command line switch? Kind of: --no-warning=stty; ... or maybe a switch to disable stty: --nostty. If I could control this by an environment variable too, it would be even more convenient (kind of: JRUBY_OPTIONS)

@enebo enebo modified the milestones: JRuby 1.7.26, JRuby 1.7.27 Aug 26, 2016

@headius

This comment has been minimized.

Show comment
Hide comment
@headius

headius Mar 15, 2017

Member

We haven't circled back to this in a while, so I think we need a refresh.

First off, I assume it still happens with 1.7.26?

Do we know that it's io/console triggering this? If so, we could just figure out the right way to silence the stty calls done there.

This is obviously a much bigger issue, but does JRuby 9.1.8.0 have the same problem?

Member

headius commented Mar 15, 2017

We haven't circled back to this in a while, so I think we need a refresh.

First off, I assume it still happens with 1.7.26?

Do we know that it's io/console triggering this? If so, we could just figure out the right way to silence the stty calls done there.

This is obviously a much bigger issue, but does JRuby 9.1.8.0 have the same problem?

@rovf

This comment has been minimized.

Show comment
Hide comment
@rovf

rovf Mar 17, 2017

It basically occurs still, but much rarer: We have now only a single output of this message in our Jenkins job, while I could see the message several times in the past. I don't know where this message exactly comes from. It's a bit difficult to retest ist with JRuby 9.x, because this is a Java 1.6 application, and I can't rund JRuby 9 on it.

In our application, we do not explicit use io/console. Since it happens only when run on Jenkins, my guess is that it has to do how Jenkins is catching the output. I don't know about the internal working of Jenkins on Windows, but Jenkins catches "the console output", and maybe Jenkins simulates a console and makes JRuby think that it is writing to a console device when it is actually writing to STDOUT or STDERR.

I wonder how many places there are in the JRuby code, where a shell-out to stty happens. If they can be identified, a quick hack would be to add a command line switch to JRuby, --no-stty, which simply forbids the use of stty.

rovf commented Mar 17, 2017

It basically occurs still, but much rarer: We have now only a single output of this message in our Jenkins job, while I could see the message several times in the past. I don't know where this message exactly comes from. It's a bit difficult to retest ist with JRuby 9.x, because this is a Java 1.6 application, and I can't rund JRuby 9 on it.

In our application, we do not explicit use io/console. Since it happens only when run on Jenkins, my guess is that it has to do how Jenkins is catching the output. I don't know about the internal working of Jenkins on Windows, but Jenkins catches "the console output", and maybe Jenkins simulates a console and makes JRuby think that it is writing to a console device when it is actually writing to STDOUT or STDERR.

I wonder how many places there are in the JRuby code, where a shell-out to stty happens. If they can be identified, a quick hack would be to add a command line switch to JRuby, --no-stty, which simply forbids the use of stty.

@headius

This comment has been minimized.

Show comment
Hide comment
@headius

headius May 5, 2017

Member

The stty locations are mostly in io/console.rb, so that would be a place to hook up stty.

We don't have a fix for this for 1.7, since we have no easy way to reproduce it right now, but I will try to add an env var that can be set to avoid using stty altogether.

Member

headius commented May 5, 2017

The stty locations are mostly in io/console.rb, so that would be a place to hook up stty.

We don't have a fix for this for 1.7, since we have no easy way to reproduce it right now, but I will try to add an env var that can be set to avoid using stty altogether.

@headius

This comment has been minimized.

Show comment
Hide comment
@headius

headius May 5, 2017

Member

I can reproduce the stty message by running it under nohup:

~/projects/jruby-1.7 $ nohup stty
nohup: ignoring input and appending output to 'nohup.out'

~/projects/jruby-1.7 $ cat nohup.out 
stty: 'standard input': Inappropriate ioctl for device
Member

headius commented May 5, 2017

I can reproduce the stty message by running it under nohup:

~/projects/jruby-1.7 $ nohup stty
nohup: ignoring input and appending output to 'nohup.out'

~/projects/jruby-1.7 $ cat nohup.out 
stty: 'standard input': Inappropriate ioctl for device

headius added a commit to headius/jruby that referenced this issue May 5, 2017

Clean up structure of io/console and avoid stty on Windows.
Fixes #3989.

* Restructure the different impls of console into their own files.
* Always use stubbed version on Windows.
* Cascade from native to stty to stubbed on other platforms.
@headius

This comment has been minimized.

Show comment
Hide comment
@headius

headius May 5, 2017

Member

@rovf I have pushed #4590 that should always use stty on Windows.

I'm not sure why it was ever intermittent for you, but I believe the problem was that cygwin does ship an stty, but Jenkins is not running your code under a proper terminal. So we had a weird perfect storm of Windows + stty + non-console that resulted in odd behavior.

If you are able to test it that would be great. Check out the branch and run ./mvnw clean package to get a working JRuby set up.

Member

headius commented May 5, 2017

@rovf I have pushed #4590 that should always use stty on Windows.

I'm not sure why it was ever intermittent for you, but I believe the problem was that cygwin does ship an stty, but Jenkins is not running your code under a proper terminal. So we had a weird perfect storm of Windows + stty + non-console that resulted in odd behavior.

If you are able to test it that would be great. Check out the branch and run ./mvnw clean package to get a working JRuby set up.

headius added a commit to headius/jruby that referenced this issue May 7, 2017

Clean up structure of io/console and avoid stty on Windows.
Fixes #3989.

* Restructure the different impls of console into their own files.
* Always use stubbed version on Windows.
* Cascade from native to stty to stubbed on other platforms.

@headius headius closed this in #4592 May 8, 2017

headius added a commit that referenced this issue May 8, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment