Bug #5475: r33507以降SolarisでPTYが使えない

• Status: Closed
• Assignee: -
• Target version: -
• ruby -v: -

[ngoto (Naohisa Goto)]

r33507以降、SolarisでPTYがまともに使えません。
% ruby -rpty -e 'PTY.spawn("/bin/cat") { |r,w,id| p r; p w; p id }'
を実行すると、
-e:1:in spawn': can't get Master/Slave device (RuntimeError) from -e:1:in '
のようになります。

make test-all では、TestIO_ConsoleはほとんどのテストがSkipされてしまいます。
TestPTYも同様に多数のSkipおよび以下のErrorが出ます。一部を抜粋します。

36. Skipped:
    test_echo(TestIO_Console) [/XXX/test/io/console/test_io_console.rb:171]:
    can't get Master/Slave device
    (中略)

37. Skipped:
    test_winsize(TestIO_Console) [/XXX/test/io/console/test_io_console.rb:171]:
    can't get Master/Slave device

38. Skipped:
    test_argv0(TestPTY) [/XXX/test/test_pty.rb:49]:
    can't get Master/Slave device
    (中略)

39. Error:
    test_pty_check_default(TestPTY):
    RuntimeError: can't get Master/Slave device
    /XXX/test/test_pty.rb:170:in spawn' /XXX/test/test_pty.rb:170:in test_pty_check_default'
    (以下略)

デバッガで追ってみると、ext/pty/pty.c:296 の grantpt(masterfd) が -1 となり、
errno は EACCES (Solaris10では13) でした。
そして、r33507で新規に導入された ext/pty/pty.c:294 の rb_fd_set_cloexec(masterfd); で masterfd に FD_CLOEXEC フラグを設定しているのが原因のようです。

Solarisでは、grantpt(3) 内部で /usr/lib/pt_chmod という setuid root されたヘルパープログラムを呼んでデバイスファイルのパーミッション設定を行っていますが、FD_CLOEXECをptyのmasterfdに設定すると、ヘルパープログラムを呼ぶ際に自動でcloseされてしまうため、ヘルパープログラムにclose済みのファイルデスクリプタが渡され、エラーになるのだろうと推測します。

On Mon, 24 Oct 2011 18:43:39 +0900
Tanaka Akira [e-mail] wrote:

とりあえずワークアランドとして以下のようにすると避けられるでしょうか。

回避できました。以下のように正常終了します。
% ruby -rpty -e 'PTY.spawn("/bin/cat") { |r,w,id| p r; p w; p id }'
#File:/dev/pts/28
#File:/dev/pts/28
16125
また、test_pty.rb, test_io_console.rb 共にSkipやErrorが消えました。

なお、Solaris 9 およびそれ以前では posix_openpt が存在しないらしいため、
defined(HAVE_PTSNAME) のところも同様に対策する必要がある気がしますが、
未だにSolaris9を使っている人が新しいRubyを求めることは無いと信じたい。

それと、Solarisを識別するマクロは __sun のほうがよいのかもしれません。
OpenCSWでは #if defined(__sun) || defined(sun) 推奨、
http://wiki.opencsw.org/porting-faq#toc18
pkgsrc developer's guide では __sun 推奨のようです。
http://www.netbsd.org/docs/pkgsrc/fixes.html#fixes.build
もっとも、sun も私の手元の Sun cc, Fujitsu fcc, gcc ではすべて
定義されていました。sun はGCCしか定義しないようです。

--
後藤 直久 [e-mail]

[akr (Akira Tanaka)]

• Status changed from Open to Closed
• % Done changed from 0 to 100

This issue was solved with changeset r33519.
Naohisa, thank you for reporting this issue.
Your contribution to Ruby is greatly appreciated.
May Ruby be with you.

---

• ext/pty/pty.c (get_device_once): delay rb_fd_set_cloexec() until
  grantpt() on Solaris. grantpt() doesn't work with CLOEXEC on
  Solaris 10.
  reported by Naohisa GOTO. [ruby-dev:44688] [Bug #5475]

[akr (Akira Tanaka)]

• ruby -v changed from ruby 2.0.0dev (2011-10-24) [sparc-solaris2.10] to -

2011年10月24日22:26 Naohisa GOTO [e-mail]:

なお、Solaris 9 およびそれ以前では posix_openpt が存在しないらしいため、
defined(HAVE_PTSNAME) のところも同様に対策する必要がある気がしますが、
未だにSolaris9を使っている人が新しいRubyを求めることは無いと信じたい。

まぁ、分かっているのに直さないのも何なのでやっておきました。

それと、Solarisを識別するマクロは __sun のほうがよいのかもしれません。
OpenCSWでは #if defined(__sun) || defined(sun) 推奨、
http://wiki.opencsw.org/porting-faq#toc18
pkgsrc developer's guide では __sun 推奨のようです。
http://www.netbsd.org/docs/pkgsrc/fixes.html#fixes.build
もっとも、sun も私の手元の Sun cc, Fujitsu fcc, gcc ではすべて
定義されていました。sun はGCCしか定義しないようです。

これもやっておきました。

ついでに、dln.c に
#if defined(sun) && defined(sparc)
というのがあって気がついたんですが、もしかして sparc も __sparc とかのほうが
いいですかね。
(うぅむ。SPARC の ABI を見ても載っていなかった...)

[田中 哲][たなか あきら][Tanaka Akira]

On Mon, 24 Oct 2011 22:59:20 +0900
Tanaka Akira [e-mail] wrote:

ついでに、dln.c に
#if defined(sun) && defined(sparc)
というのがあって気がついたんですが、もしかして sparc も __sparc とかのほうが
いいですかね。
(うぅむ。SPARC の ABI を見ても載っていなかった...)

Sun(Oracle) の cc では sparc と __sparc 両方定義がありますが、
ドキュメントでは __sparc を使うように指示がされています。
http://developers.sun.com/sunstudio/documentation/ss12u1/mr/READMEs/c++_faq.html#Vers6

ISO C厳密準拠モード(-Xc)でのみ sparc や sun は消えます。
ただし、このモードではRubyのコンパイルは通らないと思います。
http://download.oracle.com/docs/cd/E19205-01/820-1209/bjaii/index.html

私の手元にある他のコンパイラ(fcc, gcc)でも同様に
sparc と __sparc の両方が定義されています。
OpenSolaris, Illumos はおそらくSunと同様と思います。

しかし、Sparc Linux (Debianなど), NetBSD, FreeBSD, OpenBSD
など、他のsparc上のUNIX系OSでの状況はわかりませんでした。
__sparcv9 のことも考えるとさらに面倒。

--
後藤 直久 [e-mail]