IPFS Desktop should install go-ipfs as a service

[Arlodotexe]

Is your feature request related to a problem? Please describe. This feature request stemmed from an issue on Windows where IPFS was randomly going full throttle, presumably to do DHT bootstrapping or the like.

Since IPFS Desktop and go-ipfs are running as a normal user app in the system try, it treats go-ipfs with the default "normal" process priority. When CPU usage gets high, it interferes with most all other user applications that are open.

As a temporary workaround, you can restrict the number of processor cores allowed, or lower the process priority from task manager.

I've seen some Linux users use a much nicer workaround -- running go-ipfs as a service and setting the priority lower by default.

Describe the solution you'd like Having IPFS Desktop install go-ipfs as a service on Linux, Windows, etc, allows for

• Better lifecycle management
• Improved system task scheduling
• Automatic restart on failure
• Autostart on login
• Running under a different or system user.
• Automatically lowering Scheduler priority, so high CPU usage doesn't interfere with actual user apps.

Describe alternatives you've considered

• Manually setting up the service myself and using the webui instead of IPFS Desktop. A lot of hassle for something that should be enabled by default...

Additional context

[lidel]

On installation options

Unsure if installing Windows Service is worth effort: it won't improve the default installation method (per user, without admin elevation).

My rationale:

• IPFS Desktop is an Electron wrapper around go-ipfs binary (ipfs.exe).
• By default, Desktop app installs everything under normal user without the need for Administrator privilege
  • It is unlikely we will change this default: it is important for IPFS Desktop to "just work" on restricted machines, like corporate boxes, or library/school terminals managed by local IT.
  • There is an opt-in during install to do it for all users, and that requires Administrator privilege
  • In theory we could register Windows Service here, but
  • I personally have no expertise to evaluate how feasible this is, but my gut feeling is that doing it from Electorn app installer would require a lot of brittle glue code writen as NSIS installer scripts that could backfile every time Microsoft changes something in Windows.
  • :point_right: Is it even worth the effort, if the default install per user will still have these CPU/instability spikes?

How to fix it in per user install

I think Windows Service is not the solution, but adjusting process priorty could be:

• ipfs.exe is a separate process spawned by Electron app
• that means we should be able to spawn it with a low priority process, or decrease the priority after the fact
  • on Linux, decreasing priority work even on regular user – I assume Windows also allows that

Next steps

If someone wants to work on this, here are some pointers:

• IPFS Desktop internally uses js-ipfsd-ctl for spawning the go-ipfs process (this controller internally spawns ipfs.exe via execa)
• The next steps here:
  • research how can we control the priority of spawned process
    • can we do that in nodejs at the spawn time?
    • is there Windows command that allows decreasing priority of existing process after the fact?
  • (mvp) PR ipfs-desktop with PoC that adjusts the priority
  • (ideally) PR js-ipfsd-ctl with controller support for passing custom priority to be used when running external go-ipfs binary

The key is to do this with minimal amount of code that is robust against failures (ipfs.exe should run as it does not if unable to set priority).

[RubenKelevra]

• point_right Is it even worth the effort, if the default install per user will still have these CPU/instability spikes?

Well, I think so.

One advantage is, that it allows more security around the ipfs daemon through access restrictions, like we have with the hardened service for Linux/Systemd. So the worst case scenario gets much less worse if there's a security flaw in ipfs itself.

---

Regarding CPU/IO spikes, I run my service as background as possible on my Linux box, since I hardly have no CPU time to spare, but giving ipfs a fair share will just increase the overall latency of desktop operations, like open an app etc. This looks like this in systemd:

CPUSchedulingPolicy=idle
Nice=19
IOSchedulingClass=idle
IOSchedulingPriority=7

The effect is certainly noticeable, and I think I wouldn't run ipfs on this box if I couldn't put it in the background like this.