[ksh93-integration-discuss] CR 6631006 Updated, P2 shell/korn93 ksh93 hangs in situations that ksh handles okay
*Synopsis*: ksh93 hangs in situations that ksh handles okay
CR 6631006 changed on Nov 23 2009 by
=== Field === New Value = === Old Value =
Integrated in Buildsnv_128
Status 10-Fix Delivered8-Fix Available
== === ===
*Change Request ID*: 6631006
*Synopsis*: ksh93 hangs in situations that ksh handles okay
Product: solaris
Category: shell
Subcategory: korn93
Type: Defect
Subtype:
Status: 10-Fix Delivered
Substatus:
Priority: 2-High
Introduced In Release: solaris_nevada
Introduced In Build: snv_72
Responsible Engineer:
Keywords: oss-request, oss-sponsor
=== *Description*
This morning some of the elements in my $PATH were inaccessible due to
an offline NFS server. When I logged in, my GNOME terminal window
didn't give me a shell prompt. When I entered a ^C, the window went
away.
I then logged in as root and hid /usr/bin/ksh93, so that my login
scripts would use /usr/bin/ksh instead of /usr/bin/ksh93. I then
logged in as myself, and my GNOME terminal window window gave me the
expected prompt.
I then tried running ksh93 by hand; it was indeed stuck trying to
access one of the inaccessible directories:
athyra$ truss -p 8666
stat("/ws/onnv-tools/onbld/bin", 0x7FFFE588) (sleeping...)
This appears to be hard to recover from, since one usually needs a
functional shell before one can change one's shell.
ksh93 needs to be at least as robust as the Solaris ksh in
circumstances like this before it can replace the Solaris ksh.
And there's some question in my mind whether ksh93 should be the
default root shell if it hangs in situations like this. (Though I
suppose it's questionable practice for root to have NFS directories in
its PATH. So maybe this isn't a critical issue.)
*** (#1 of 2): 2007-11-16 18:04:11 GMT+00:00
[dep, 15Apr2009]
This is especially bad considering ksh93 is installed as /bin/sh,
which means every system(3C) call will hang on startup regardless of
its dependence on PATH resolution beyond known local entries (usually
first in one's path for this reason).
*** (#2 of 2): 2009-04-16 00:44:28 GMT+00:00
=== *Public Comments*
Are you able to reproduce it with build 111?
*** (#1 of 6): 2009-04-16 07:32:20 GMT+00:00
[dep, 16Apr2009]
ksh93 appears to have the same behavior on build 112.
*** (#2 of 6): 2009-04-16 20:14:59 GMT+00:00
[dep, 13Aug2009]
(In response to an unnecessarily non-public comment claiming this has
something to do with fancy stuck filesystem detection in Sun's ksh88,
and that somehow caching file descriptors and using openat will
magically solve the problem.)
There is *NOT* a matter of Sun's ksh detecting stuck filesystems.
This is a matter of ksh93 scanning your entire path on startup,
whereas Sun's ksh (and more importantly, sh) simply did not.
Period.
My PATH:
; echo $PATH
/home/dep/private/bin:/home/dep/bin/i386:/home/dep/bin:/usr/bin:/usr/sbin:/usr/openwin/bin:/usr/sfw/bin:/ws/onnv-tools/SUNWspro/SS11/bin:/ws/onnv-tools/SUNWspro/SOS8/bin:/ws/onnv-tools/onbld/bin:/ws/onnv-tools/onbld/bin/i386:/usr/ccs/bin:/usr/java/bin
Eliminate effect of dot files:
; mkdir /tmp/foo
; HOME=/tmp/foo
stats and opens from ksh (or /usr/xpg4/bin/sh):
; truss -t stat,open ksh
stat64("/usr/bin/ksh", 0x08047608) = 0
open("/var/ld/ld.config", O_RDONLY) Err#2 ENOENT
stat64("/lib/libc.so.1", 0x08046E08)= 0
open("/lib/libc.so.1", O_RDONLY)= 3
stat64("/home/dep", 0x080476F0) = 0
stat64(".", 0x08047780) = 0
stat64("/home/dep", 0x08047720) = 0
stat64(".", 0x080477B0) = 0
stat64("/home/dep", 0x08047720) = 0
stat64(".", 0x080477B0) = 0
open64("", O_RDWR|O_APPEND|O_CREAT, 0600) Err#2 ENOENT
open64("/tmp/sh827332.1", O_RDWR|O_CREAT|O_EXCL, 0600) = 3
$
stats and opens from sh:
; truss -t stat,open sh
stat64("/sbin/sh", 0x08047610) = 0
open("/var/ld/ld.config", O_RDONLY) Err#2 ENOENT
stat64("/lib/libc.so.1", 0x08046E10)= 0
open("/lib/libc.so.1", O_RDONLY)= 3
$
stats and opens from ksh93:
; truss -t stat,open ksh93
stat64("/usr/bin/ksh93", 0x08047604)= 0
open("/var/ld/ld.config", O_RDONLY) Err#2 ENOENT
stat64("/lib/libc.so.1", 0x08046E04)= 0
open("/lib/libc.so.1", O_RDONLY)= 3
open("/proc/self/auxv", O_RDONLY) = 3
stat("/usr/bin/amd64/ksh93", 0xFD7FFFDFF550) = 0
ope
[ksh93-integration-discuss] CR 6631006 Updated, P2 shell/korn93 ksh93 hangs in situations that ksh handles okay
*Synopsis*: ksh93 hangs in situations that ksh handles okay
CR 6631006 changed on Oct 28 2009 by
=== Field === New Value = === Old Value =
Commit to Fix in Build snv_128 snv_127
Fixed in Build snv_128
Program Management Fix Integrated into Source New Defect
Status 8-Fix Available 7-Fix in Progress
== === ===
*Change Request ID*: 6631006
*Synopsis*: ksh93 hangs in situations that ksh handles okay
Product: solaris
Category: shell
Subcategory: korn93
Type: Defect
Subtype:
Status: 8-Fix Available
Substatus:
Priority: 2-High
Introduced In Release: solaris_nevada
Introduced In Build: snv_72
Responsible Engineer:
Keywords: oss-request, oss-sponsor
=== *Description*
This morning some of the elements in my $PATH were inaccessible due to
an offline NFS server. When I logged in, my GNOME terminal window
didn't give me a shell prompt. When I entered a ^C, the window went
away.
I then logged in as root and hid /usr/bin/ksh93, so that my login
scripts would use /usr/bin/ksh instead of /usr/bin/ksh93. I then
logged in as myself, and my GNOME terminal window window gave me the
expected prompt.
I then tried running ksh93 by hand; it was indeed stuck trying to
access one of the inaccessible directories:
athyra$ truss -p 8666
stat("/ws/onnv-tools/onbld/bin", 0x7FFFE588) (sleeping...)
This appears to be hard to recover from, since one usually needs a
functional shell before one can change one's shell.
ksh93 needs to be at least as robust as the Solaris ksh in
circumstances like this before it can replace the Solaris ksh.
And there's some question in my mind whether ksh93 should be the
default root shell if it hangs in situations like this. (Though I
suppose it's questionable practice for root to have NFS directories in
its PATH. So maybe this isn't a critical issue.)
*** (#1 of 2): 2007-11-16 18:04:11 GMT+00:00
[dep, 15Apr2009]
This is especially bad considering ksh93 is installed as /bin/sh,
which means every system(3C) call will hang on startup regardless of
its dependence on PATH resolution beyond known local entries (usually
first in one's path for this reason).
*** (#2 of 2): 2009-04-16 00:44:28 GMT+00:00
=== *Public Comments*
Are you able to reproduce it with build 111?
*** (#1 of 6): 2009-04-16 07:32:20 GMT+00:00
[dep, 16Apr2009]
ksh93 appears to have the same behavior on build 112.
*** (#2 of 6): 2009-04-16 20:14:59 GMT+00:00
[dep, 13Aug2009]
(In response to an unnecessarily non-public comment claiming this has
something to do with fancy stuck filesystem detection in Sun's ksh88,
and that somehow caching file descriptors and using openat will
magically solve the problem.)
There is *NOT* a matter of Sun's ksh detecting stuck filesystems.
This is a matter of ksh93 scanning your entire path on startup,
whereas Sun's ksh (and more importantly, sh) simply did not.
Period.
My PATH:
; echo $PATH
/home/dep/private/bin:/home/dep/bin/i386:/home/dep/bin:/usr/bin:/usr/sbin:/usr/openwin/bin:/usr/sfw/bin:/ws/onnv-tools/SUNWspro/SS11/bin:/ws/onnv-tools/SUNWspro/SOS8/bin:/ws/onnv-tools/onbld/bin:/ws/onnv-tools/onbld/bin/i386:/usr/ccs/bin:/usr/java/bin
Eliminate effect of dot files:
; mkdir /tmp/foo
; HOME=/tmp/foo
stats and opens from ksh (or /usr/xpg4/bin/sh):
; truss -t stat,open ksh
stat64("/usr/bin/ksh", 0x08047608) = 0
open("/var/ld/ld.config", O_RDONLY) Err#2 ENOENT
stat64("/lib/libc.so.1", 0x08046E08)= 0
open("/lib/libc.so.1", O_RDONLY)= 3
stat64("/home/dep", 0x080476F0) = 0
stat64(".", 0x08047780) = 0
stat64("/home/dep", 0x08047720) = 0
stat64(".", 0x080477B0) = 0
stat64("/home/dep", 0x08047720) = 0
stat64(".", 0x080477B0) = 0
open64("", O_RDWR|O_APPEND|O_CREAT, 0600) Err#2 ENOENT
open64("/tmp/sh827332.1", O_RDWR|O_CREAT|O_EXCL, 0600) = 3
$
stats and opens from sh:
; truss -t stat,open sh
stat64("/sbin/sh", 0x08047610) = 0
open("/var/ld/ld.config", O_RDONLY) Err#2 ENOENT
stat64("/lib/libc.so.1", 0x08046E10)= 0
open("/lib/libc.so.1", O_RDONLY)= 3
$
stats and opens from ksh93:
; truss -t stat,open ksh93
stat64("/usr/bin/ksh93", 0x08047604)= 0
open("/var/ld/ld.config", O_RDONLY) Err#2 ENOENT
stat64("/lib/libc.so.1", 0x08046E04)= 0
open("/lib/libc
[ksh93-integration-discuss] CR 6631006 Updated, P2 shell/korn93 ksh93 hangs in situations that ksh handles okay
*Synopsis*: ksh93 hangs in situations that ksh handles okay
CR 6631006 changed on Oct 23 2009 by
=== Field === New Value = === Old Value =
See Also 6793763
See Also 6437624
== === ===
*Change Request ID*: 6631006
*Synopsis*: ksh93 hangs in situations that ksh handles okay
Product: solaris
Category: shell
Subcategory: korn93
Type: Defect
Subtype:
Status: 7-Fix in Progress
Substatus:
Priority: 2-High
Introduced In Release: solaris_nevada
Introduced In Build: snv_72
Responsible Engineer:
Keywords: oss-request, oss-sponsor
=== *Description*
This morning some of the elements in my $PATH were inaccessible due to
an offline NFS server. When I logged in, my GNOME terminal window
didn't give me a shell prompt. When I entered a ^C, the window went
away.
I then logged in as root and hid /usr/bin/ksh93, so that my login
scripts would use /usr/bin/ksh instead of /usr/bin/ksh93. I then
logged in as myself, and my GNOME terminal window window gave me the
expected prompt.
I then tried running ksh93 by hand; it was indeed stuck trying to
access one of the inaccessible directories:
athyra$ truss -p 8666
stat("/ws/onnv-tools/onbld/bin", 0x7FFFE588) (sleeping...)
This appears to be hard to recover from, since one usually needs a
functional shell before one can change one's shell.
ksh93 needs to be at least as robust as the Solaris ksh in
circumstances like this before it can replace the Solaris ksh.
And there's some question in my mind whether ksh93 should be the
default root shell if it hangs in situations like this. (Though I
suppose it's questionable practice for root to have NFS directories in
its PATH. So maybe this isn't a critical issue.)
*** (#1 of 2): 2007-11-16 18:04:11 GMT+00:00
[dep, 15Apr2009]
This is especially bad considering ksh93 is installed as /bin/sh,
which means every system(3C) call will hang on startup regardless of
its dependence on PATH resolution beyond known local entries (usually
first in one's path for this reason).
*** (#2 of 2): 2009-04-16 00:44:28 GMT+00:00
=== *Public Comments*
Are you able to reproduce it with build 111?
*** (#1 of 6): 2009-04-16 07:32:20 GMT+00:00
[dep, 16Apr2009]
ksh93 appears to have the same behavior on build 112.
*** (#2 of 6): 2009-04-16 20:14:59 GMT+00:00
[dep, 13Aug2009]
(In response to an unnecessarily non-public comment claiming this has
something to do with fancy stuck filesystem detection in Sun's ksh88,
and that somehow caching file descriptors and using openat will
magically solve the problem.)
There is *NOT* a matter of Sun's ksh detecting stuck filesystems.
This is a matter of ksh93 scanning your entire path on startup,
whereas Sun's ksh (and more importantly, sh) simply did not.
Period.
My PATH:
; echo $PATH
/home/dep/private/bin:/home/dep/bin/i386:/home/dep/bin:/usr/bin:/usr/sbin:/usr/openwin/bin:/usr/sfw/bin:/ws/onnv-tools/SUNWspro/SS11/bin:/ws/onnv-tools/SUNWspro/SOS8/bin:/ws/onnv-tools/onbld/bin:/ws/onnv-tools/onbld/bin/i386:/usr/ccs/bin:/usr/java/bin
Eliminate effect of dot files:
; mkdir /tmp/foo
; HOME=/tmp/foo
stats and opens from ksh (or /usr/xpg4/bin/sh):
; truss -t stat,open ksh
stat64("/usr/bin/ksh", 0x08047608) = 0
open("/var/ld/ld.config", O_RDONLY) Err#2 ENOENT
stat64("/lib/libc.so.1", 0x08046E08)= 0
open("/lib/libc.so.1", O_RDONLY)= 3
stat64("/home/dep", 0x080476F0) = 0
stat64(".", 0x08047780) = 0
stat64("/home/dep", 0x08047720) = 0
stat64(".", 0x080477B0) = 0
stat64("/home/dep", 0x08047720) = 0
stat64(".", 0x080477B0) = 0
open64("", O_RDWR|O_APPEND|O_CREAT, 0600) Err#2 ENOENT
open64("/tmp/sh827332.1", O_RDWR|O_CREAT|O_EXCL, 0600) = 3
$
stats and opens from sh:
; truss -t stat,open sh
stat64("/sbin/sh", 0x08047610) = 0
open("/var/ld/ld.config", O_RDONLY) Err#2 ENOENT
stat64("/lib/libc.so.1", 0x08046E10)= 0
open("/lib/libc.so.1", O_RDONLY)= 3
$
stats and opens from ksh93:
; truss -t stat,open ksh93
stat64("/usr/bin/ksh93", 0x08047604)= 0
open("/var/ld/ld.config", O_RDONLY) Err#2 ENOENT
stat64("/lib/libc.so.1", 0x08046E04)= 0
open("/lib/libc.so.1", O_RDONLY)= 3
open("/proc/self/auxv", O_RDONLY) = 3
stat("/usr/bin/amd64/ksh93", 0xFD7FFFDFF550) = 0
op
[ksh93-integration-discuss] CR 6631006 Updated, P2 shell/korn93 ksh93 hangs in situations that ksh handles okay
*Synopsis*: ksh93 hangs in situations that ksh handles okay
CR 6631006 changed on Oct 7 2009 by
=== Field === New Value = === Old Value =
Public CommentsNew Note
== === ===
*Change Request ID*: 6631006
*Synopsis*: ksh93 hangs in situations that ksh handles okay
Product: solaris
Category: shell
Subcategory: korn93
Type: Defect
Subtype:
Status: 5-Cause Known
Substatus:
Priority: 2-High
Introduced In Release:
Introduced In Build:
Responsible Engineer:
Keywords:
=== *Description*
This morning some of the elements in my $PATH were inaccessible due to
an offline NFS server. When I logged in, my GNOME terminal window
didn't give me a shell prompt. When I entered a ^C, the window went
away.
I then logged in as root and hid /usr/bin/ksh93, so that my login
scripts would use /usr/bin/ksh instead of /usr/bin/ksh93. I then
logged in as myself, and my GNOME terminal window window gave me the
expected prompt.
I then tried running ksh93 by hand; it was indeed stuck trying to
access one of the inaccessible directories:
athyra$ truss -p 8666
stat("/ws/onnv-tools/onbld/bin", 0x7FFFE588) (sleeping...)
This appears to be hard to recover from, since one usually needs a
functional shell before one can change one's shell.
ksh93 needs to be at least as robust as the Solaris ksh in
circumstances like this before it can replace the Solaris ksh.
And there's some question in my mind whether ksh93 should be the
default root shell if it hangs in situations like this. (Though I
suppose it's questionable practice for root to have NFS directories in
its PATH. So maybe this isn't a critical issue.)
*** (#1 of 2): 2007-11-16 18:04:11 GMT+00:00
[dep, 15Apr2009]
This is especially bad considering ksh93 is installed as /bin/sh,
which means every system(3C) call will hang on startup regardless of
its dependence on PATH resolution beyond known local entries (usually
first in one's path for this reason).
*** (#2 of 2): 2009-04-16 00:44:28 GMT+00:00
=== *Public Comments*
Are you able to reproduce it with build 111?
*** (#1 of 6): 2009-04-16 07:32:20 GMT+00:00
[dep, 16Apr2009]
ksh93 appears to have the same behavior on build 112.
*** (#2 of 6): 2009-04-16 20:14:59 GMT+00:00
[dep, 13Aug2009]
(In response to an unnecessarily non-public comment claiming this has
something to do with fancy stuck filesystem detection in Sun's ksh88,
and that somehow caching file descriptors and using openat will
magically solve the problem.)
There is *NOT* a matter of Sun's ksh detecting stuck filesystems.
This is a matter of ksh93 scanning your entire path on startup,
whereas Sun's ksh (and more importantly, sh) simply did not.
Period.
My PATH:
; echo $PATH
/home/dep/private/bin:/home/dep/bin/i386:/home/dep/bin:/usr/bin:/usr/sbin:/usr/openwin/bin:/usr/sfw/bin:/ws/onnv-tools/SUNWspro/SS11/bin:/ws/onnv-tools/SUNWspro/SOS8/bin:/ws/onnv-tools/onbld/bin:/ws/onnv-tools/onbld/bin/i386:/usr/ccs/bin:/usr/java/bin
Eliminate effect of dot files:
; mkdir /tmp/foo
; HOME=/tmp/foo
stats and opens from ksh (or /usr/xpg4/bin/sh):
; truss -t stat,open ksh
stat64("/usr/bin/ksh", 0x08047608) = 0
open("/var/ld/ld.config", O_RDONLY) Err#2 ENOENT
stat64("/lib/libc.so.1", 0x08046E08)= 0
open("/lib/libc.so.1", O_RDONLY)= 3
stat64("/home/dep", 0x080476F0) = 0
stat64(".", 0x08047780) = 0
stat64("/home/dep", 0x08047720) = 0
stat64(".", 0x080477B0) = 0
stat64("/home/dep", 0x08047720) = 0
stat64(".", 0x080477B0) = 0
open64("", O_RDWR|O_APPEND|O_CREAT, 0600) Err#2 ENOENT
open64("/tmp/sh827332.1", O_RDWR|O_CREAT|O_EXCL, 0600) = 3
$
stats and opens from sh:
; truss -t stat,open sh
stat64("/sbin/sh", 0x08047610) = 0
open("/var/ld/ld.config", O_RDONLY) Err#2 ENOENT
stat64("/lib/libc.so.1", 0x08046E10)= 0
open("/lib/libc.so.1", O_RDONLY)= 3
$
stats and opens from ksh93:
; truss -t stat,open ksh93
stat64("/usr/bin/ksh93", 0x08047604)= 0
open("/var/ld/ld.config", O_RDONLY) Err#2 ENOENT
stat64("/lib/libc.so.1", 0x08046E04)= 0
open("/lib/libc.so.1", O_RDONLY)= 3
open("/proc/self/auxv", O_RDONLY) = 3
stat("/usr/bin/amd64/ksh93", 0xFD7FFFDFF550) = 0
open("/var/ld/64/ld.config", O_RDONLY) Err#2 ENOENT
stat("/lib/64/libc.so.1", 0xFD7FFFDFE9F0) = 0
open("/li
[ksh93-integration-discuss] CR 6631006 Updated, P2 shell/korn93 ksh93 hangs in situations that ksh handles okay
*Synopsis*: ksh93 hangs in situations that ksh handles okay
CR 6631006 changed on Oct 6 2009 by
=== Field === New Value = === Old Value =
Evaluation New Note
Status 5-Cause Known 3-Accepted
== === ===
*Change Request ID*: 6631006
*Synopsis*: ksh93 hangs in situations that ksh handles okay
Product: solaris
Category: shell
Subcategory: korn93
Type: Defect
Subtype:
Status: 5-Cause Known
Substatus:
Priority: 2-High
Introduced In Release:
Introduced In Build:
Responsible Engineer:
Keywords:
=== *Description*
This morning some of the elements in my $PATH were inaccessible due to
an offline NFS server. When I logged in, my GNOME terminal window
didn't give me a shell prompt. When I entered a ^C, the window went
away.
I then logged in as root and hid /usr/bin/ksh93, so that my login
scripts would use /usr/bin/ksh instead of /usr/bin/ksh93. I then
logged in as myself, and my GNOME terminal window window gave me the
expected prompt.
I then tried running ksh93 by hand; it was indeed stuck trying to
access one of the inaccessible directories:
athyra$ truss -p 8666
stat("/ws/onnv-tools/onbld/bin", 0x7FFFE588) (sleeping...)
This appears to be hard to recover from, since one usually needs a
functional shell before one can change one's shell.
ksh93 needs to be at least as robust as the Solaris ksh in
circumstances like this before it can replace the Solaris ksh.
And there's some question in my mind whether ksh93 should be the
default root shell if it hangs in situations like this. (Though I
suppose it's questionable practice for root to have NFS directories in
its PATH. So maybe this isn't a critical issue.)
*** (#1 of 2): 2007-11-16 18:04:11 GMT+00:00
[dep, 15Apr2009]
This is especially bad considering ksh93 is installed as /bin/sh,
which means every system(3C) call will hang on startup regardless of
its dependence on PATH resolution beyond known local entries (usually
first in one's path for this reason).
*** (#2 of 2): 2009-04-16 00:44:28 GMT+00:00
=== *Public Comments*
Are you able to reproduce it with build 111?
*** (#1 of 5): 2009-04-16 07:32:20 GMT+00:00
[dep, 16Apr2009]
ksh93 appears to have the same behavior on build 112.
*** (#2 of 5): 2009-04-16 20:14:59 GMT+00:00
[dep, 13Aug2009]
(In response to an unnecessarily non-public comment claiming this has
something to do with fancy stuck filesystem detection in Sun's ksh88,
and that somehow caching file descriptors and using openat will
magically solve the problem.)
There is *NOT* a matter of Sun's ksh detecting stuck filesystems.
This is a matter of ksh93 scanning your entire path on startup,
whereas Sun's ksh (and more importantly, sh) simply did not.
Period.
My PATH:
; echo $PATH
/home/dep/private/bin:/home/dep/bin/i386:/home/dep/bin:/usr/bin:/usr/sbin:/usr/openwin/bin:/usr/sfw/bin:/ws/onnv-tools/SUNWspro/SS11/bin:/ws/onnv-tools/SUNWspro/SOS8/bin:/ws/onnv-tools/onbld/bin:/ws/onnv-tools/onbld/bin/i386:/usr/ccs/bin:/usr/java/bin
Eliminate effect of dot files:
; mkdir /tmp/foo
; HOME=/tmp/foo
stats and opens from ksh (or /usr/xpg4/bin/sh):
; truss -t stat,open ksh
stat64("/usr/bin/ksh", 0x08047608) = 0
open("/var/ld/ld.config", O_RDONLY) Err#2 ENOENT
stat64("/lib/libc.so.1", 0x08046E08)= 0
open("/lib/libc.so.1", O_RDONLY)= 3
stat64("/home/dep", 0x080476F0) = 0
stat64(".", 0x08047780) = 0
stat64("/home/dep", 0x08047720) = 0
stat64(".", 0x080477B0) = 0
stat64("/home/dep", 0x08047720) = 0
stat64(".", 0x080477B0) = 0
open64("", O_RDWR|O_APPEND|O_CREAT, 0600) Err#2 ENOENT
open64("/tmp/sh827332.1", O_RDWR|O_CREAT|O_EXCL, 0600) = 3
$
stats and opens from sh:
; truss -t stat,open sh
stat64("/sbin/sh", 0x08047610) = 0
open("/var/ld/ld.config", O_RDONLY) Err#2 ENOENT
stat64("/lib/libc.so.1", 0x08046E10)= 0
open("/lib/libc.so.1", O_RDONLY)= 3
$
stats and opens from ksh93:
; truss -t stat,open ksh93
stat64("/usr/bin/ksh93", 0x08047604)= 0
open("/var/ld/ld.config", O_RDONLY) Err#2 ENOENT
stat64("/lib/libc.so.1", 0x08046E04)= 0
open("/lib/libc.so.1", O_RDONLY)= 3
open("/proc/self/auxv", O_RDONLY) = 3
stat("/usr/bin/amd64/ksh93", 0xFD7FFFDFF550) = 0
open("/var/ld/64/ld.config", O_RDONLY) Err
[ksh93-integration-discuss] CR 6631006 Updated, P2 shell/korn93 ksh93 hangs in situations that ksh handles okay
*Synopsis*: ksh93 hangs in situations that ksh handles okay
CR 6631006 changed on Sep 17 2009 by
=== Field === New Value = === Old Value =
Public CommentsNew Note
== === ===
*Change Request ID*: 6631006
*Synopsis*: ksh93 hangs in situations that ksh handles okay
Product: solaris
Category: shell
Subcategory: korn93
Type: Defect
Subtype:
Status: 3-Accepted
Substatus:
Priority: 2-High
Introduced In Release:
Introduced In Build:
Responsible Engineer:
Keywords:
=== *Description*
This morning some of the elements in my $PATH were inaccessible due to
an offline NFS server. When I logged in, my GNOME terminal window
didn't give me a shell prompt. When I entered a ^C, the window went
away.
I then logged in as root and hid /usr/bin/ksh93, so that my login
scripts would use /usr/bin/ksh instead of /usr/bin/ksh93. I then
logged in as myself, and my GNOME terminal window window gave me the
expected prompt.
I then tried running ksh93 by hand; it was indeed stuck trying to
access one of the inaccessible directories:
athyra$ truss -p 8666
stat("/ws/onnv-tools/onbld/bin", 0x7FFFE588) (sleeping...)
This appears to be hard to recover from, since one usually needs a
functional shell before one can change one's shell.
ksh93 needs to be at least as robust as the Solaris ksh in
circumstances like this before it can replace the Solaris ksh.
And there's some question in my mind whether ksh93 should be the
default root shell if it hangs in situations like this. (Though I
suppose it's questionable practice for root to have NFS directories in
its PATH. So maybe this isn't a critical issue.)
*** (#1 of 2): 2007-11-16 18:04:11 GMT+00:00
[dep, 15Apr2009]
This is especially bad considering ksh93 is installed as /bin/sh,
which means every system(3C) call will hang on startup regardless of
its dependence on PATH resolution beyond known local entries (usually
first in one's path for this reason).
*** (#2 of 2): 2009-04-16 00:44:28 GMT+00:00
=== *Public Comments*
Are you able to reproduce it with build 111?
*** (#1 of 5): 2009-04-16 07:32:20 GMT+00:00
[dep, 16Apr2009]
ksh93 appears to have the same behavior on build 112.
*** (#2 of 5): 2009-04-16 20:14:59 GMT+00:00
[dep, 13Aug2009]
(In response to an unnecessarily non-public comment claiming this has
something to do with fancy stuck filesystem detection in Sun's ksh88,
and that somehow caching file descriptors and using openat will
magically solve the problem.)
There is *NOT* a matter of Sun's ksh detecting stuck filesystems.
This is a matter of ksh93 scanning your entire path on startup,
whereas Sun's ksh (and more importantly, sh) simply did not.
Period.
My PATH:
; echo $PATH
/home/dep/private/bin:/home/dep/bin/i386:/home/dep/bin:/usr/bin:/usr/sbin:/usr/openwin/bin:/usr/sfw/bin:/ws/onnv-tools/SUNWspro/SS11/bin:/ws/onnv-tools/SUNWspro/SOS8/bin:/ws/onnv-tools/onbld/bin:/ws/onnv-tools/onbld/bin/i386:/usr/ccs/bin:/usr/java/bin
Eliminate effect of dot files:
; mkdir /tmp/foo
; HOME=/tmp/foo
stats and opens from ksh (or /usr/xpg4/bin/sh):
; truss -t stat,open ksh
stat64("/usr/bin/ksh", 0x08047608) = 0
open("/var/ld/ld.config", O_RDONLY) Err#2 ENOENT
stat64("/lib/libc.so.1", 0x08046E08)= 0
open("/lib/libc.so.1", O_RDONLY)= 3
stat64("/home/dep", 0x080476F0) = 0
stat64(".", 0x08047780) = 0
stat64("/home/dep", 0x08047720) = 0
stat64(".", 0x080477B0) = 0
stat64("/home/dep", 0x08047720) = 0
stat64(".", 0x080477B0) = 0
open64("", O_RDWR|O_APPEND|O_CREAT, 0600) Err#2 ENOENT
open64("/tmp/sh827332.1", O_RDWR|O_CREAT|O_EXCL, 0600) = 3
$
stats and opens from sh:
; truss -t stat,open sh
stat64("/sbin/sh", 0x08047610) = 0
open("/var/ld/ld.config", O_RDONLY) Err#2 ENOENT
stat64("/lib/libc.so.1", 0x08046E10)= 0
open("/lib/libc.so.1", O_RDONLY)= 3
$
stats and opens from ksh93:
; truss -t stat,open ksh93
stat64("/usr/bin/ksh93", 0x08047604)= 0
open("/var/ld/ld.config", O_RDONLY) Err#2 ENOENT
stat64("/lib/libc.so.1", 0x08046E04)= 0
open("/lib/libc.so.1", O_RDONLY)= 3
open("/proc/self/auxv", O_RDONLY) = 3
stat("/usr/bin/amd64/ksh93", 0xFD7FFFDFF550) = 0
open("/var/ld/64/ld.config", O_RDONLY) Err#2 ENOENT
stat("/lib/64/libc.so.1", 0xFD7FFFDFE9F0) = 0
open("/lib/
[ksh93-integration-discuss] CR 6631006 Updated, P2 shell/korn93 ksh93 hangs in situations that ksh handles okay
*Synopsis*: ksh93 hangs in situations that ksh handles okay
CR 6631006 changed on Sep 17 2009 by
=== Field === New Value = === Old Value =
Public CommentsNew Note
== === ===
*Change Request ID*: 6631006
*Synopsis*: ksh93 hangs in situations that ksh handles okay
Product: solaris
Category: shell
Subcategory: korn93
Type: Defect
Subtype:
Status: 3-Accepted
Substatus:
Priority: 2-High
Introduced In Release:
Introduced In Build:
Responsible Engineer:
Keywords:
=== *Description*
This morning some of the elements in my $PATH were inaccessible due to
an offline NFS server. When I logged in, my GNOME terminal window
didn't give me a shell prompt. When I entered a ^C, the window went
away.
I then logged in as root and hid /usr/bin/ksh93, so that my login
scripts would use /usr/bin/ksh instead of /usr/bin/ksh93. I then
logged in as myself, and my GNOME terminal window window gave me the
expected prompt.
I then tried running ksh93 by hand; it was indeed stuck trying to
access one of the inaccessible directories:
athyra$ truss -p 8666
stat("/ws/onnv-tools/onbld/bin", 0x7FFFE588) (sleeping...)
This appears to be hard to recover from, since one usually needs a
functional shell before one can change one's shell.
ksh93 needs to be at least as robust as the Solaris ksh in
circumstances like this before it can replace the Solaris ksh.
And there's some question in my mind whether ksh93 should be the
default root shell if it hangs in situations like this. (Though I
suppose it's questionable practice for root to have NFS directories in
its PATH. So maybe this isn't a critical issue.)
*** (#1 of 2): 2007-11-16 18:04:11 GMT+00:00
[dep, 15Apr2009]
This is especially bad considering ksh93 is installed as /bin/sh,
which means every system(3C) call will hang on startup regardless of
its dependence on PATH resolution beyond known local entries (usually
first in one's path for this reason).
*** (#2 of 2): 2009-04-16 00:44:28 GMT+00:00
=== *Public Comments*
Are you able to reproduce it with build 111?
*** (#1 of 4): 2009-04-16 07:32:20 GMT+00:00
[dep, 16Apr2009]
ksh93 appears to have the same behavior on build 112.
*** (#2 of 4): 2009-04-16 20:14:59 GMT+00:00
[dep, 13Aug2009]
(In response to an unnecessarily non-public comment claiming this has
something to do with fancy stuck filesystem detection in Sun's ksh88,
and that somehow caching file descriptors and using openat will
magically solve the problem.)
There is *NOT* a matter of Sun's ksh detecting stuck filesystems.
This is a matter of ksh93 scanning your entire path on startup,
whereas Sun's ksh (and more importantly, sh) simply did not.
Period.
My PATH:
; echo $PATH
/home/dep/private/bin:/home/dep/bin/i386:/home/dep/bin:/usr/bin:/usr/sbin:/usr/openwin/bin:/usr/sfw/bin:/ws/onnv-tools/SUNWspro/SS11/bin:/ws/onnv-tools/SUNWspro/SOS8/bin:/ws/onnv-tools/onbld/bin:/ws/onnv-tools/onbld/bin/i386:/usr/ccs/bin:/usr/java/bin
Eliminate effect of dot files:
; mkdir /tmp/foo
; HOME=/tmp/foo
stats and opens from ksh (or /usr/xpg4/bin/sh):
; truss -t stat,open ksh
stat64("/usr/bin/ksh", 0x08047608) = 0
open("/var/ld/ld.config", O_RDONLY) Err#2 ENOENT
stat64("/lib/libc.so.1", 0x08046E08)= 0
open("/lib/libc.so.1", O_RDONLY)= 3
stat64("/home/dep", 0x080476F0) = 0
stat64(".", 0x08047780) = 0
stat64("/home/dep", 0x08047720) = 0
stat64(".", 0x080477B0) = 0
stat64("/home/dep", 0x08047720) = 0
stat64(".", 0x080477B0) = 0
open64("", O_RDWR|O_APPEND|O_CREAT, 0600) Err#2 ENOENT
open64("/tmp/sh827332.1", O_RDWR|O_CREAT|O_EXCL, 0600) = 3
$
stats and opens from sh:
; truss -t stat,open sh
stat64("/sbin/sh", 0x08047610) = 0
open("/var/ld/ld.config", O_RDONLY) Err#2 ENOENT
stat64("/lib/libc.so.1", 0x08046E10)= 0
open("/lib/libc.so.1", O_RDONLY)= 3
$
stats and opens from ksh93:
; truss -t stat,open ksh93
stat64("/usr/bin/ksh93", 0x08047604)= 0
open("/var/ld/ld.config", O_RDONLY) Err#2 ENOENT
stat64("/lib/libc.so.1", 0x08046E04)= 0
open("/lib/libc.so.1", O_RDONLY)= 3
open("/proc/self/auxv", O_RDONLY) = 3
stat("/usr/bin/amd64/ksh93", 0xFD7FFFDFF550) = 0
open("/var/ld/64/ld.config", O_RDONLY) Err#2 ENOENT
stat("/lib/64/libc.so.1", 0xFD7FFFDFE9F0) = 0
open("/lib/
