fche changed the topic of #systemtap to: http://sourceware.org/systemtap; email systemtap@sourceware.org if answers here not timely, conversations may be logged
<agentzh>
so procfs is buggy?
<agentzh>
seems it is a regression caused by commit 4706ab3ca "runtime: default to using procfs for the transport"?
<fche>
well now you got me curious, will do some testing here
<agentzh>
reverting that single commit makes things work again on fedora 28.
<fche>
fedora what?!
<kerneltoast>
agentzh, that commit isn't the bug, it just makes -DSTAP_TRANS_PROCFS the default
<agentzh>
yeah, i knew.
<fche>
what's your uname -r ?
<fche>
agentzh, it works okay on the various kernels I've tried, going back to rhel6 era
<agentzh>
fche: interesting. we'll see if it's something specific to our own branch.
<agentzh>
hmm, the upstream master branch gives the same error, even for a hello world oneliner.
<agentzh>
i'm using a 5.0.16 kernel.
<kerneltoast>
maybe stap can't access procfs without root
<fche>
not sure I have any system running that-ish here
<fche>
sudo stap ... works?
<kerneltoast>
fche, we don't use sudo
<agentzh>
oh, i've using normal user.
<kerneltoast>
we use the stapsys group stuff
<agentzh>
*been
<fche>
understood, but check
<kerneltoast>
agentzh, me too
<fche>
maybe /proc is mounted peculiarly on your OS
<kerneltoast>
sudo works
<kerneltoast>
lol
<agentzh>
ah
<agentzh>
yeah, sudo works for me too.
<agentzh>
anyway to work around that?
<agentzh>
forcing debugfs?
<agentzh>
any better way?
<fche>
how is your procfs etc. mounted?
<agentzh>
how to check?
<agentzh>
$ file /proc
<agentzh>
/proc: directory
<agentzh>
$ df /proc
<agentzh>
Filesystem 1K-blocks Used Available Use% Mounted on