fche changed the topic of #systemtap to: http://sourceware.org/systemtap; email systemtap@sourceware.org if answers here not timely, conversations may be logged
<mnaser>
I'm using systemtap to look at some io problems that im dealing with, i got a list of all writes but some processes are doing open()s on non-relative file paths, is there a while to gt the cwd/pwd in systemtap probe?
<fche>
hi mnaser
<mnaser>
hello
<fche>
off the top of my head, we don't have a function for that already in the library, but probably doable
<mnaser>
my little workaround was ... lsof -p the pid as soon as i saw it but that's obviously not ideal
<fche>
e.g. the pfiles.stp sample lists open files belonging to a process, kind of like lsof
<mnaser>
that can be a good asset
<mnaser>
oh that's a lot of code.
<mnaser>
heh
<fche>
it does its dirty work by looking inside the kernel task_struct -> files[]
<fche>
the cwd is somewhere in the vicinity
<fche>
but yeah, too much code & too much embedded-C rather than script
<fche>
but it's a possible way forward in the short term
<fche>
see also the env_var() function in the tapset
<mnaser>
fche: what about username (instead of uid)
<fche>
that does another task_struct search
<fche>
user names don't exist at the kernel level, only numbers
<fche>
one could pass the /etc/passwd database into a stap script e.g. using a tool to generate a stap script fragment that initializes a lookup table with items like that
<mnaser>
fche: i see, makes sense... basically trying to see which user is generating the most iops but i think i can deal with uid and convert to user later (at least at this point, this is what im comfortable with in stap)
<fche>
(you can have a little /bin/sh or perl wrapper script that generates the lookup table and the rest of the stap script)
<mnaser>
yeah that's what im thinking
<fche>
hm, maybe we should have a stap cron job that generates such a lookup tables into /usr/share/systemtap/tapset periodically, moohahaha
<mnaser>
im happy i got to find out what was the process stealing iops