Report generated from sosreport within my snap is incomplete

Hello!

I’m developing a tool written in python that uses sosreport to generate a report containing a lot of log files and things like lspci and lsusb outputs.

I just noticed that, although a sosreport is generated and contains some data, a lot of the output is empty. For instance, the lspci output is 0 bytes.

If I run the same command from the Debian package installed on the same laptop (sudo sosreport --batch), I get a different sosreport, and this time the lspci -nnvv logs contain a lot of data.

I tried accessing my snap through a shell and checked that I could use lscpi, and it works:

$ snap run --shell qabro
$ cd $SNAP/usr/bin/
$ sudo ./lspci -nnvv                                                                
00:00.0 Host bridge [0600]: Intel Corporation Device [8086:5904] (rev 02)                                                    
        Subsystem: Dell Device [1028:07b8]                                                                   
        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
        Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ >SERR- <PERR- INTx-
        Latency: 0                                                                                         
        Capabilities: [e0] Vendor Specific Information: Len=10 <?>  
(…)

How can I make sure sosreport can access the proper information and provide a useful report/logs?

For info:

try adding the hardware-observe and perhaps also log-observe interfaces to your app.

Thanks for the tip.

I modified the apps part of my snapcraft.yaml file as follow (added the plugs lines):

apps:
  qabro:
    command: qabro
    plugs: [hardware-observe, log-observe, mount-observe, network-observe, network-setup-observe, physical-memory-observe, system-observe, upower-observe]
    environment:
      LD_LIBRARY_PATH: $LD_LIBRARY_PATH:$SNAP/lib/fwts

  sosreport:
    command: sosreport
    plugs: [hardware-observe, log-observe, mount-observe, network-observe, network-setup-observe, physical-memory-observe, system-observe, upower-observe]

I then built a snap, installed it on my device, and ran:

$  snap connect qabro:hardware-observe core:hardware-observe
$  snap connect qabro:log-observe core:log-observe
$  snap connect qabro:upower-observe core:upower-observe
$  snap connect qabro:mount-observe core:mount-observe
$  snap connect qabro:network-observe core:network-observe
$  snap connect qabro:network-setup-observe core:network-setup-observe
$  snap connect qabro:physical-memory-observe core:physical-memory-observe
$  snap connect qabro:system-observe core:system-observe

I finally ran the following command to generate a log report:

sudo qabro.sosreport --batch --tmp-dir ~

The report was created, but most of the output files are still empty (the output of lspci is 0 bytes, for instance). When comparing before/after adding the interfaces, the reports look identical.

Not sure what to do.

@ogra, question: when running snap connect qabro:... core:..., every app within my qabro snap that are using this plug should be connected, right? In my case, I’m talking about sosreport.

(of course, I started by only adding the hardware-observe and log-observe interfaces as you mentioned, @ogra, but the result was the same)

does your snap ship lspci ? i dont think such stuff is in the core snap so you need to ship it yourself …

yes, that is correct

It currently doesn’t ship lspci, but I am testing on a 18.04 desktop image. My understanding was that if a command launched from within the snap couldn’t be found inside the snap, it would try to reach for system-wide installed commands (at least on a desktop install). Am I wrong?

I tried to install my snap in classic mode (using exactly the same snap, I installed it with sudo snap install snap_name.snap --classic --dangerous) but running qabro.sosreport still provide the same report, with empty lspci log files etc.

OK, I tried including lspci this way:

(…)
apps:
(…)

  lspci:
    command: lspci
(…)
parts:
(…)
  lspci:
    plugin: nil
    stage-packages:
      - pciutils
      - libc6
      - libkmod2
      - libpci3
(…)

I can run qbro.lspci and even qabro.lspci -nvv properly, but sosreport still returns empty lspci log files…

To be clear, I run this command:

sudo qabro.sosreport -o pci --batch --tmp-dir ~

It generates a .tar.xz report in my home directory that contains a /sosreport-20180727153034/sos_commands/pci/ directory with two files:

  • lspci_-nnvv (0 bytes)
  • lspci_-tv (0 bytes)

I’m not sure what to do…

my guess is that sosreport uses a hardcoded path for lspci trying to call it from /usr/bin instead of $SNAP/usr/bin

That would certainly be a problem that I would need to deal with on devices running UC16, but that should at least work on my 18.04 desktop image then, no?

# on my 18.04 desktop:
$ ll /usr/bin/lspci
-rwxr-xr-x 1 root root 80K Apr 25  2017 /usr/bin/lspci

That’s not the case and that’s what I don’t understand.

all snaps run on top of the core snap, it is the execution environment for your snap.

some selected parts of the actual rootfs of the host machine are visible (via bind mounting) in /var/lib/snapd/hostfs where the confinement setup provides them …
the / that a snap sees at runtime is what you find in /snap/core/current/ though.

the snap environment is completely distinct from the hosts rootfs (else confinement would not work and it would also be pretty complicated to have snaps run on multiple different distros and releases) and provides a unified set of libs, binaries and versions that do not change (a 16.04 base for core 16 and 18.04 base for the upcoming core18)

you can try out what a snap sees as its envionment by using: snap run --shell <snapname>.<appname>, take a look at the environment there …

1 Like

Thanks for the feeback and sorry I didn’t get back to you earlier, it took me a while to find the time to debug this.

It looks like you were right. It seems that sosreport hardcodes the $PATH depending on the Linux version found.

I’ve tried modifying the linked line to hardcode the snap directory of my app, and… it works!

I have to find a way to bypass this issue, but your initial guess was very helpful. Thanks!