public inbox for systemtap@sourceware.org
 help / color / mirror / Atom feed
* [Bug runtime/27224] New: stap 4.4 'cannot attach to module' in debugfs mode as non-root
@ 2021-01-22  4:26 craig.ringer at 2ndquadrant dot com
  2021-01-22  4:26 ` [Bug runtime/27224] " craig.ringer at 2ndquadrant dot com
                   ` (7 more replies)
  0 siblings, 8 replies; 9+ messages in thread
From: craig.ringer at 2ndquadrant dot com @ 2021-01-22  4:26 UTC (permalink / raw)
  To: systemtap

https://sourceware.org/bugzilla/show_bug.cgi?id=27224

            Bug ID: 27224
           Summary: stap 4.4 'cannot attach to module' in debugfs mode as
                    non-root
           Product: systemtap
           Version: unspecified
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: runtime
          Assignee: systemtap at sourceware dot org
          Reporter: craig.ringer at 2ndquadrant dot com
  Target Milestone: ---

On Fedora 33 with kernel 5.9.16-200.fc33.x86_64 and stap 4.4/0.182, rpm
4.4-2.fc33 I noticed that staprun can't seem to attach to module I/O anymore.
It fails with

    ERROR: Cannot attach to module stap_nnn control channel; not running?
    ERROR: 'stap_nnn' is not a zombie systemtap module.

The issue arises with no explicit transport selection or with
-DSTAP_TRANS_DEBUGFS explicitly requested.

This has also been reported by a colleague on Debian who is using "Systemtap
translator/driver (version 4.4/0.176, Debian version 4.4-1~bpo10+1
(buster-backports))"

Running stap with sudo has no effect.

WORKAROUND
========== 

I have been able to work around the error with:

    sudo mount /sys/kernel/debug -o remount,mode=755

DETAIL
======

I found the above info the ancient Debian bug report
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=706817 from 2013, and it
references a 2012 Linux kernel patch
http://lkml.iu.edu/hypermail/linux/kernel/1201.3/00626.html . Also
https://github.com/torvalds/linux/commit/82aceae4f0d42f03d9ad7d1e90389e731153898f
 .

But remounting debugfs solves this issue despite the last relevant changes I
can find related to debugfs being 7 or 8 years old.

It might be related to the changes in systemtap intended to work around the
kernel lockdown issues and add procfs transport support, per
https://bugzilla.redhat.com/show_bug.cgi?id=1873492 in commit 7615cae79 ?

Running with -DSTAP_TRANS_PROCFS output instead works, but only when stap
itself is run as root, even though staprun is setuid root. Unclear why, perhaps
a separate issue.

I don't see the same problem when running on a self-compiled version of git
master @ HEAD = d7ea535c6 but I don't yet know if that's due to differences in
configuration and installation for packages vs source builds, or whether it's
down to a code change since the 4.4 release. I'll compile 4.4 to see.

Sample output for various runs is attached.

-- 
You are receiving this mail because:
You are the assignee for the bug.

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2021-01-29 10:43 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-01-22  4:26 [Bug runtime/27224] New: stap 4.4 'cannot attach to module' in debugfs mode as non-root craig.ringer at 2ndquadrant dot com
2021-01-22  4:26 ` [Bug runtime/27224] " craig.ringer at 2ndquadrant dot com
2021-01-22  4:27 ` craig.ringer at 2ndquadrant dot com
2021-01-22  4:31 ` craig.ringer at 2ndquadrant dot com
2021-01-22  4:42 ` craig.ringer at 2ndquadrant dot com
2021-01-22  4:42 ` [Bug runtime/27224] stap 4.4 'cannot attach to module' in debugfs mode as non-root (WITH WORKAROUND) craig.ringer at 2ndquadrant dot com
2021-01-22 22:30 ` fche at redhat dot com
2021-01-22 22:31 ` fche at redhat dot com
2021-01-29 10:43 ` craig.ringer at 2ndquadrant dot com

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).