the IPFS companion is disabled even with Kubo is running

[siiky]

Describe the bug

Starting with one of the latest 2 or 3 releases, the IPFS companion seems to be disabled from time to time, even if Kubo is running.

When that happens, if I open a site such as ipfs.tech, it'll load through HTTP instead of redirecting to http://ipfs.tech.ipns.localhost:8081. If I hit the icon on the browser to open the companion menu, it'll then connect to Kubo and everything works as usual.

To Reproduce

I haven't found a pattern, it just happens sometimes... I can be sure that Kubo is running, however -- notice the Active line, it's been up for 2 weeks and 3 days:

$ systemctl --user status ipfs
● ipfs.service - InterPlanetary File System (IPFS) daemon
     Loaded: loaded (/home/$USER/.config/systemd/user/ipfs.service; enabled; preset: enabled)
     Active: active (running) since Sun 2023-09-10 20:13:23 WEST; 2 weeks 3 days ago
       Docs: https://docs.ipfs.io/
   Main PID: 1277 (ipfs)
      Tasks: 139 (limit: 38327)
     Memory: 652.9M (swap max: 0B)
        CPU: 1h 59min 29.095s
     CGroup: /user.slice/user-1001.slice/[email protected]/app.slice/ipfs.service
             └─1277 /home/$USER/.local/bin/ipfs daemon --migrate

Sep 10 20:54:19 $HOSTNAME ipfs[1277]: ⚠️ Your system might be struggling to keep up with DHT reprovides!
Sep 10 20:54:19 $HOSTNAME ipfs[1277]: This means your content could partially or completely inaccessible on the network.
Sep 10 20:54:19 $HOSTNAME ipfs[1277]: We observed that you recently provided 129 keys at an average rate of 16.295281359s per key.
Sep 10 20:54:19 $HOSTNAME ipfs[1277]: 🕑 An attempt to estimate your blockstore size timed out after 5 minutes,
Sep 10 20:54:19 $HOSTNAME ipfs[1277]: implying your blockstore might be exceedingly large. Assuming a considerable
Sep 10 20:54:19 $HOSTNAME ipfs[1277]: size of 10TiB, it would take 379707h34m35.70358272s to provide the complete set.
Sep 10 20:54:19 $HOSTNAME ipfs[1277]: ⏰ The total provide time needs to stay under your reprovide interval (22h0m0s) to prevent falling behind!
Sep 10 20:54:19 $HOSTNAME ipfs[1277]: 💡 Consider enabling the Accelerated DHT to enhance your system performance. See:
Sep 10 20:54:19 $HOSTNAME ipfs[1277]: https://github.com/ipfs/kubo/blob/master/docs/config.md#routingaccelerateddhtclient
Sep 10 22:15:09 $HOSTNAME ipfs[1277]: 2023/09/10 22:15:09 http: superfluous response.WriteHeader call from github.com/prometheus/client_golang/prometheus/promhttp.(*responseWriterDelegator).WriteHeader (delegator.go:65)

(Those logs are from more than 2 weeks ago, they don't seem related? Could be wrong... I just didn't get around to taking care of that yet.)

Expected behavior

If Kubo is running, the companion should automatically connect and stay connected.

Desktop (please complete the following information):

• OS: Debian testing
• Browser: Firefox 119.0b2
• IPFS companion: 3.1.0

[welcome[bot]]

Thank you for submitting your first issue to this repository! A maintainer will be here shortly to triage and review. In the meantime, please double-check that you have provided all the necessary information to make this process easy! Any information that can help save additional round trips is useful! We currently aim to give initial feedback within seven business days. If this does not happen, feel free to leave a comment. Please keep an eye on how this issue will be labeled, as labels give an overview of priorities, assignments and additional actions requested by the maintainers:

• "Priority" labels will show how urgent this is for the team.
• "Status" labels will show if this is ready to be worked on, blocked, or in progress.
• "Need" labels will indicate if additional input or analysis is required.

Finally, remember to use https://discuss.ipfs.io if you just need general support.

[whizzzkid]

Thanks for submitting this issue @siiky, did you notice a pattern between sleeps? in the new companion MV3 implementation, the companion can actually go to sleep as companion does not interact with an active request. However the browser should already have the rule and this should automatically redirect.

I'll try reproducing this (not been successful so far) but this most likely looks like a bug with the MV3 implementation in chromium browser as per preliminary investigation.

Please keep me posted if you find a reliable way to reproduce or the problem worsens.

[siiky]

Hey @whizzzkid, thanks for taking a look. I noticed that the companion is offline whenever I open the browser, i.e., if I close and open the browser again, it'll be offline. Note that I'm using Firefox, not Chromium/Chrome (maybe that's not what you meant, just wanted to clarify). Also added to the report the companion version I'm currently using: 3.1.0.

However the browser should already have the rule and this should automatically redirect.

That's kind of working. With the companion offline, if I open e.g. ipns://ipfs.tech/, I'll be redirected to https://ipfs-tech.ipns.dweb.link/ instead of to http://ipfs.tech.ipns.localhost:8081/

[lloy0076]

I'm experiencing the same thing in https://github.com/ipfs/ipfs-webui/commit/a43dd23 on FireFox in Windows (118.0.1 (64-bit)) and the extension claims it's 3.1.0.

[lloy0076]

Indeed, unless I manually click on it and force it to activate, it doesn't redirect me to my Kubo node (which almost defeats the purpose of why I run it).

[lloy0076]

I'll try reproducing this (not been successful so far) but this most likely looks like a bug with the MV3 implementation in chromium browser as per preliminary investigation.

It's happening in FireFox on Windows too - I don't know if it's just Chromium browsers.

[lloy0076]

I'll try reproducing this (not been successful so far) but this most likely looks like a bug with the MV3 implementation in chromium browser as per preliminary investigation.

It's happening in FireFox on Windows too - I don't know if it's just Chromium browsers.

And strangely enough, 3.1.0 on Chrome Version 117.0.5938.134 (Official Build) (64-bit) (Windows) DOES NOT display this odd behaviour.

[whizzzkid]

Thanks @siiky and @lloy0076 I'm still unable to reproduce it. Firefox in MV3 has has replaced background event pages which goes to sleep just like service workers do in chrome. However, I need more to investigate on why firefox is not waking up the extension when a request comes through 🤔.

[siiky]

@whizzzkid What version of Firefox are you using? I noticed this happens on another one of my laptops, both using Firefox beta. Could be Firefox beta specifically..?

[lloy0076]

I'm not using beta versions of Firefox, though and it is happening to me. See my above reports.

On 9 Oct 2023 07:47,

siiky @.***> wrote: @whizzzkid What version of Firefox are you using? I noticed this happens on another one of my ptops, both using Firefox beta. Could be Firefox beta specifically..?

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.***

[lloy0076]

I've also verified it doesn't activate on FireFox 117.0 on Manjaro Linux too; and in fact although it detects the number of peers setup, the "My Node" doesn't activate until I interact with the settings; or open and close the tool:

See:

[github-actions[bot]]

Oops, seems like we needed more information for this issue, please comment with more details or this issue will be closed in 7 days.

[lloy0076]

@whizzzkid What's confusing? It doesn't work on the version of FireFox I've got installed in Manjaro linux as well. Sometimes I've noticed that even the same versions of FireFox work subtly differently depending on one's operating system?

[whizzzkid]

@lloy0076 Looks like this is isolated to firefox on linux. This is not happening on mac, to verify, I tried:

• Companion/kubo is running, mac lid is closed, mac lid is opened and companion is still running.
• Companion/kubo is running, mac goes to sleep, mac sleeps for the entire night, in the morning companion is still running.
• Companion/kubo is running, firefox is untouched for quite a few hours, firefox is brought to focus, companion is still running.
• kubo is not running, firefox/companion is running, mac goes to sleep, mac wakes up, kubo is started, companion shows activity just fine.

I think I need to try this on a linux machine to reproduce, unless there is reliable way to reproduce this. Next time this happens, can you please go to:

• about:debugging#/runtime/this-firefox
• Click on Inspect
• Save all messages to logs:
• Make sure the logs do not contain PII, Share the logs here.

[lloy0076]

The background script is not running and it happens on:

• Firefox 118.0.2 64 bit

Running on WINDOWS too

[lloy0076]

Step 1. Install Windows 11 PRO Step 2. Install FireFox Step 3. Install IPFS Companion

Step 4. Find some kubo instance running on the local network or on a network that you know should work Step 5. Configure IPFS companion in the setup to point at the above kubo in step 4.

http://192.168.2.11:5001 --> The KUBO RPC url
http://192.168.2.11:8080 --> The local gateway
# obviously your particular IPs or DNS names or URLs might differ here

Of course make sure that the kubo / ipfs "thing" works; that one does; see the attached image. But DO NOT be confused that the icon is "working" --> it only works when you click it, wait 10-30 seconds or more etc (because the inspector clearly says that background thread isn't running).

[lloy0076]

Do ALL the above but install Manjaro Linux somehow (e.g. this ISO is the particular one I used: manjaro-gnome-23.0-230903-linux65.iso).

@whizzzkid NOTE that I only installed it on Linux to see if FireFox on Linux had the same issue. I don't usually use Linux for Desktop stuff (I'd like to, but too much stuff I use is Windows dependent but this is off topic).

The only reason I put it on Linux was to see if, for some stupid reason, the underlying OS affected the issue. I would hazard a guess it's got something to do with the FireFox version(s).

What the issue I am seeing is NOT:

• It is NOT that the Kubo node (at 192.168.2.11) is not working - it is working and it will serve up files via IPFS directly or via any of its peers
• It doesn't appear to be specifically Windows FireFox
• It DID used to "work" but I don't know what upgraded (it could be that FireFox did an upgrade...I don't usually notice such things because things don't usually break)

[lloy0076]

NB. https://ipfs.io/ipfs/QmcjKJDsEdXmRmgjvhE9CfPdjk2gB9AMUBurbarnwkiJoe might work: it should say:

Hi Github and Whizzkid etc. This should work!```

It is pinned to my local and that node is usually behaving itself: nonetheless it can be somewhat flaky.

[hsn10]

I have this problem in brave. Solved by de installing extension, go to brave settings and check "IPFS companion" checkbox. it got installed again and now it works ok.