Snap --ltrace

Hello,

The question from the PR is whether it makes sense for snap to get an ltrace option? (https://github.com/snapcore/snapd/pull/7849)

Meanwhile i think that it would be sufficient if you could start ltrace with all variables from the snap.

The call could look like this:
snap run <snap_name> --cmd=“ltrace -f”

For example for ltrace is at least LD_LIBRARY_PATH required.

1 Like

How well does ltrace work if you use it with snap run outside of snap confinement like (untested):

$ ltrace -f snap run <snap_name>

?

Until now it seems to work in the most cases.

For desktop snap’s it won’t work, in my case.

But good news.
If i build “ltrace” inside, then i could find the function-calls

So i will close the PR now.

Sorry I didn’t mean to say that we shouldn’t have this in snapd, what I’m specifically curious about is:

How does it not work? Can you provide me with an example of it not working?

Yes but we don’t want to have every snap author have to do this as it is tedious and cumber-some. The reason we included strace inside snapd with --strace=... was that there are certain syscalls that basically cause the exec-chain to hang when they are not excluded, so we exclude those when folks run with snap run --strace=....

If there are similar things with ltrace, then it makes sense I think to include some form of ltrace support in snapd.

1 Like

Hello, I’m also interested in the native support of ltrace as strace’s output doesn’t specifically point out the library function(s) I need to override in the case of the snapped application hardcoding some of the paths.

In my case, the call seems to be terminated with the following message prematurely:

[pid 4004768] memcpy(0x10faaa0, "/snap/core20/current\0", 21) = 0x10faaa0
[pid 4004768] getenv("SNAP_CONFINE_DEBUG")       = nil
[pid 4004768] getenv("SNAPD_DEBUG")              = nil
[pid 4004768] getenv("SNAP_CONFINE_DEBUG")       = nil
[pid 4004768] getenv("SNAPD_DEBUG")              = nil
[pid 4004768] getenv("SNAP_CONFINE_DEBUG")       = nil
[pid 4004768] getenv("SNAPD_DEBUG")              = nil
[pid 4004768] getenv("SNAP_CONFINE_DEBUG")       = nil
[pid 4004768] getenv("SNAPD_DEBUG")              = nil
[pid 4004768] getresuid(0x7ffd37543d94, 0x7ffd37543d98, 0x7ffd37543d9c, 0xfffffffc) = 0
[pid 4004768] getresgid(0x7ffd37543da0, 0x7ffd37543da4, 0x7ffd37543da8, 0x7fa1d941043b) = 0
[pid 4004768] getenv("SNAP_CONFINE_DEBUG")       = nil
[pid 4004768] getenv("SNAPD_DEBUG")              = nil
[pid 4004768] getenv("SNAP_CONFINE_DEBUG")       = nil
[pid 4004768] getenv("SNAPD_DEBUG")              = nil
[pid 4004768] __errno_location()                 = 0x7fa1d9322f70
[pid 4004768] __vfprintf_chk(0x7fa1d953e6a0, 1, 0x415aaa, 0x7ffd37543ca0need to run as root or suid) = 27
[pid 4004768] fputc('\n', 0x7fa1d953e6a0
)        = 10
[pid 4004768] exit(1 <no return ...>
[pid 4004768] +++ exited (status 1) +++

(full output)

It seems that the trace doesn’t seem to get passed to the snapped application, at all.

I have to install the snap in --devmode for the ltrace command to work.