Jesús Cea Avión <j...@jcea.es> added the comment:
The LD_LIBRARY_PATH is because I am compiling Python as a shared lib and, of
course, I am not installing the development version in the usual system path.
That is, it is not a requirement for this project, but an easy to follow
procedure for unexperienced betatesters.
About the permissions, the situation is messy because under Solaris a regular
user can not run dtrace unless special permissions be assigned to her. The
situation is something like this: (talking about Solaris 10):
* Global Zone:
- root: dtrace works.
- Regular user: dtrace is going to show a "permission denied" error, unless an
admin had set dtrace user/proc permissions to him. If that is the case, it
works.
* Non Global Zone:
- root: dtrace seems to work, but no probes can be found unless special dtrace
user/proc permissions are assigned to the zone.
- regular user: dtrace is going to show a "permission denied" error, unless an
admin had set dtrace user/proc permissions to him. In that case, it will behave
like "root". That is, no probes found unles the zone have the right
capabilities.
The permission denied error can be easily detected and managed, but the
"silent" error is not distinguible of this project not working. I am thinking
about trying first an "always present" well known probe, to detect when the
kernel is activelly ignoring dtrace instead of giving a clear permission error.
I have requested to the sysadmins of my OpenIndiana buildbots to activate
dtrace (of user code) in my zone, so I can evaluate the behaviour under
OpenIndiana/Illumos.
A couple of details I want to document here, to remember then and to ask for
advice:
- I have added a "sys.trace_capabilities", so a program can know if any
system-trace functionality is compiled in. Current values are "None" and
"("dtrace", "Sun")". Maybe create a new "dtrace" module could be appropiate,
instead, with "dtrace.supported=True/False", but I am thinking about future
MacOS probes, Linux "systemtap" probes, etc.
- Current code only traces function calls *TO* Python code. If the function
calls is to C code (os.getpid(), for instance), the call is not visible. I
think this is a major deficience, apparently shared by all the previous
attempts I have seen (including official Sun probes).
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue13405>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
