*Synopsis*: pgrep can't find scriptname when script is run by ksh93
CR 6680532 changed on Mar 18 2010 by <User 1-2OEE9N>
=== Field ============ === New Value ============= === Old Value =============
SR 1-595709401
Functionality Primary
Hardware ultrasparc
Impact Significant
Operating System solaris_nevada
Product Build snv_135
Product Name solaris
Product Release solaris_nevada
Severity 2
====================== =========================== ===========================
*Change Request ID*: 6680532
*Synopsis*: pgrep can't find scriptname when script is run by ksh93
Product: solaris
Category: library
Subcategory: libproc
Type: Defect
Subtype:
Status: 5-Cause Known
Substatus:
Priority: 2-High
Introduced In Release:
Introduced In Build:
Responsible Engineer:
Keywords:
=== *Description* ============================================================
If I have a script called, say, "mmm", which is run by ksh93 (invoked either
as ksh or as ksh93), then "pgrep mmm" returns nothing. If it's run by ksh88
then it returns the process id.
pgrepping for "ksh" returns the pid for the ksh93 case, but not for the ksh88
case.
*** (#1 of 2): 2008-03-26 20:14:43 GMT+00:00 <User 1-5Q-2233>
Not only is this a diffrence between ksh88 and ksh93 it is different to what
happens with
zsh and bash (both of those have the same behaviour as ksh88):
For example:
portellen:pts/3$ ./foo &
[1] 22120
portellen:pts/3$ pargs 22120
22120: /bin/ksh -p ./foo
argv[0]: /bin/ksh
argv[1]: /bin/ksh
argv[2]: ./foo
portellen:pts/3$ pgrep foo
portellen:pts/3$ pgrep -f foo
22120
portellen:pts/3$ ./bar &
[2] 24841
portellen:pts/3$ pargs 24841
24841: /bin/zsh -p ./bar
argv[0]: /bin/zsh
argv[1]:
argv[2]: ./bar
portellen:pts/3$ pgrep bar
24841
portellen:pts/3$ ./baz &
[3] 29439
portellen:pts/3$ pargs 29439
29439: /bin/bash -p ./baz
argv[0]: /bin/bash
argv[1]: -p
argv[2]: ./baz
portellen:pts/3$ pgrep baz
29439
portellen:pts/3$ cat foo
#!/bin/ksh -p
sleep 300
portellen:pts/3$ cat bar
#!/bin/zsh -p
sleep 300
portellen:pts/3$ cat baz
#!/bin/bash -p
sleep 300
*** (#2 of 2): 2009-07-29 13:44:43 GMT+00:00 <User 1-5Q-14842>
=== *Public Comments* ========================================================
All other shell are not isaexeced. Did you try to use ksh93 binary directly?
Any reason why it should be ksh93 bug if pgrep is using /proc interface?
*** (#1 of 6): 2009-07-29 21:29:37 GMT+00:00 <User 1-1SURPB>
After more than month no updates. Closing as not a defect.
*** (#2 of 6): 2009-08-31 09:29:26 GMT+00:00 <User 1-1SURPB>
It appears that running with /usr/bin/i86/ksh93 makes it work fine. The issue
seems to be that the wrapper code that's installed as /usr/bin/ksh itself execs
/usr/bin/ksh93 directly. If it were to exec /usr/bin/i86/ksh93, I would expect
the problem to also go away, but it doesn't. It looks like it has something to
do with the fact that there's an exec call.
I'm moving this to libproc, as it does seem pretty clear that it's not a ksh93
problem.
*** (#3 of 6): 2009-08-31 17:08:57 GMT+00:00 <User 1-5Q-2233>
After discussing with ksh93 folks, it seems to be limitation with isaexec. So
transfering it back to libproc.
*** (#4 of 6): 2009-09-02 12:11:21 GMT+00:00 <User 1-GN0KC>
Even if it is a limiation in isaexec it is because ksh93 is installed with
isaexec unlike all the other shells that we have this problem. I really still
don't understand why the default for /usr/bin/ksh93 needs to be the 64 bit
version.
*** (#5 of 6): 2009-09-02 12:25:30 GMT+00:00 <User 1-5Q-14842>
The result of PSARC/2006/550
I do not know what were the reasons for this, but I see benefits in speed and
automatic transition of commands to 64-bit (bypassing limits of 32-bit world
like timestamps).
Yes, other shells are not isaexed. Like many other tools are not isaexeced.
If somebody feels it was not correct decision, I would recommend to open
discussion in ksh93 project integration mailing list (<email address omitted>).
*** (#6 of 6): 2009-09-02 12:46:40 GMT+00:00 <User 1-1SURPB>
=== *Workaround* =============================================================
Adding "-f" to the pgrep line finds the ksh93 versions.
*** (#1 of 3): 2009-07-29 13:44:43 GMT+00:00 <User 1-5Q-14842>
>From Roland Mainz:
for OS/Net >= B121 compile your scripts with
$ /usr/bin/shcomp <scriptname> <execname>
*** (#2 of 3): 2009-07-29 21:37:16 GMT+00:00 <User 1-1SURPB>
*** Last Edit: 2009-07-29 21:37:38 GMT+00:00 <User 1-1SURPB>
Remove the isaexec link for /usr/bin/ksh93 and make /usr/bin/ksh93 the 32 bit
version.
This puts ksh93 in the same position as all the other shells.
*** (#3 of 3): 2009-09-02 12:26:18 GMT+00:00 <User 1-5Q-14842>
=== *Additional Details* =====================================================
Targeted Release:
Commit To Fix In Build:
Fixed In Build:
Integrated In Build:
Verified In Build:
See Also:
Duplicate of:
Hooks:
Hook1:
Hook2:
Hook3:
Hook4:
Hook5:
Hook6:
Program Management:
Root Cause:
Fix Affects Documentation: No
Fix Affects Localization: No
=== *History* ================================================================
Date Submitted: 2008-03-26 20:14:43 GMT+00:00
Submitted By: <User 1-5Q-2233>
Status Changed Date Updated Updated By
3-Accepted 2008-08-21 00:33:23 GMT+00:00 <User 1-5Q-5151>
2-Incomplete 2009-07-29 21:29:37 GMT+00:00 <User 1-1SURPB>
11-Closed 2009-08-31 09:29:26 GMT+00:00 <User 1-1SURPB>
1-Dispatched 2009-08-31 17:08:57 GMT+00:00 <User 1-5Q-2233>
5-Cause Known 2009-09-02 09:42:46 GMT+00:00 <User 1-GN0KC>
=== *Service Request* ========================================================
Impact: Significant
Functionality: Primary
Severity: 2
Product Name: solaris
Product Release: solaris_nevada
Product Build:
Operating System: solaris
Hardware: generic
Submitted Date: 2008-03-26 20:14:43 GMT+00:00
=== *Service Request* ========================================================
Impact: Significant
Functionality: Primary
Severity: 2
Product Name: solaris
Product Release: solaris_nevada
Product Build: snv_135
Operating System: solaris_nevada
Hardware: ultrasparc
Submitted Date: 2010-03-18 09:55:09 GMT+00:00
=== *Multiple Release (MR) Cluster* - 0 ======================================
