Why has `flatpak search` been so slow, a few times?

Fedora/RHEL
, ,
1

Any idea of why flatpak search required so much time to complete, recently?

It reproduced multiple times in quick succession, but it has not reproduced since it completed.

I am aware that my internet connection speed varies:

However, that log demonstrates incredible slowness:

real    3m14.527s 
user    0m2.724s 
sys     0m2.269s

…mostly due to:

14:46:30 (+     0.000039) ppoll([{fd=19, events=POLLIN}], 1, NULL, NULL, 8) = ? ERESTARTNOHAND (To be restarted if no handler) <1.953186>
14:46:32 (+     1.953285) --- SIGWINCH {si_signo=SIGWINCH, si_code=SI_KERNEL} ---
14:46:32 (+     0.000054) ppoll([{fd=19, events=POLLIN}], 1, NULL, NULL, 8) = ? ERESTARTNOHAND (To be restarted if no handler) <28.543964>
14:47:01 (+    28.544180) --- SIGWINCH {si_signo=SIGWINCH, si_code=SI_KERNEL} ---
14:47:01 (+     0.000054) ppoll([{fd=19, events=POLLIN}], 1, NULL, NULL, 8) = ? ERESTARTNOHAND (To be restarted if no handler) <8.866604>
14:47:09 (+     8.866742) --- SIGWINCH {si_signo=SIGWINCH, si_code=SI_KERNEL} ---
14:47:09 (+     0.000084) ppoll([{fd=19, events=POLLIN}], 1, NULL, NULL, 8) = 1 ([{fd=19, revents=POLLIN}]) <21.457578>
2

I CANNOT state with certainty, however network intrusions in recent days have been strong; there are still numerous servers that are completely “off-line” or shut down because of these “issues”.

3

Hi @RokeJulianLockhart,

I might be totally barking up de wrong tree here, but in the off chance that I’m right and it helps, I’ll post it

Since you’re in the UK, does your (cable)modem/router run on an Intel Puma chipset (the usual choice for british cable providers) ?

Due to some terrible designflaws those modem/routers will (under load) often kind of virtually “freeze” up to several times a day for a very limited but unspecified amount of time after which they continue again as if nothing happened.

It might not be the issue that you’re facing (OTOH it might be) , but no harm in checking anyway. :slight_smile:

4

@tkn, some weeks before this, I switched to a StarLink modem-router:

It is a somewhat new model (a UTR-251), which does not appear to utilise that chip:

5

Your own numbers point at the answer. real is 3m14s, but user and sys add up to about 5 seconds. So flatpak spent almost the whole time sitting there waiting on something, not actually working. The strace shows the same thing: it’s parked in ppoll on fd 19 for 2 to 28 seconds at a time. The SIGWINCH lines are just your terminal window getting resized, which interrupts the wait and restarts it. They’re noise.

So the real question is what fd 19 was. My guess is a network connection pulling appstream data from Flathub. That would also explain why it stopped happening once it finished. Once the data is cached locally, searches go back to being instant. Your speedtests wouldn’t catch that either, since a slow or flaky Flathub mirror can crawl even when your connection itself is fine.

If it comes back, these two would tell us for sure. The -yy flag makes strace show what each fd actually is, like a TCP connection with its IP and port or a D-Bus socket, instead of just a number:

strace -f -tt -T -yy -o flatpak.log flatpak search firefox

flatpak -v search firefox

If fd 19 turns out to be a TCP socket to Flathub’s CDN, it’s on their end. If it’s a unix socket like the D-Bus system bus, then it was waiting on the flatpak system helper or polkit, which would be a different rabbit hole.

One part of this is my guess, not something I verified. I don’t know for sure that flatpak search refreshes Flathub’s appstream data on its own when it’s stale. That’s why the reply frames it as a guess and gives him the -yy run, which will show definitively what fd 19 was.