Troubles when reverting to older version of IPFS

[RMBLRX]

So your script automatically installed v0.4.13, and I was having some trouble with that version locking up my system (presumably out of memory from every indication I had that the memory usage was steadily climbing, and the fact that others seem to have this issue with v0.4.13), so I thought to revert to a lower version (v0.4.9, which supposedly doesn't have that issue) and managed to get IPFS uninstalled and reinstalled at that version with the script. I noticed, however, that in this process the script will not work if IPFS is not running and and return >>> Failed to stop IPFS, and so I had to start IPFS to get it to work; no big deal but a bit quirky.

However, I had further trouble in attempting a reverse migration (which is the recommendation in the output when the daemon attempts to start with repos of a higher version in ~/.ipfs), and so I decided to try the more current IPFS version (v0.4.17) but soon discovered that the script would not work with this low of an IPFS version and fails to stop IPFS, presumably because ipfs-daemon is an unknown instance at this low of a version (the service seems to be called ipfs daemon instead, but even ipfs\ daemon shows up as an unrecognized service when I attempt to stop it).

Obviously I was able to simply run sudo rm -rf /usr/local/bin/ipfs to basically start from scratch and was able to install 0.4.17 afterward, but I figured you might like to know about this little snag. Incidentally, for some reason I was also unable to restore my pins with the subsequent migration, but that's all on me and IPFS's own repo-migration script. Now I just have to wait and see if this newer version runs out of memory.

[claudiobizzotto]

Thanks for reporting these issues.

1. "the script will not work if IPFS is not running and return '>>> Failed to stop IPFS', and so I had to start IPFS to get it to work;"

I couldn't replicate this one. The script should only return that message when the IPFS daemon is running. So, if the daemon isn't running, that step should have been skipped, but I'm not sure why that didn't happen in your scenario.

This is what I did to check that it still works (from the project's root directory):

$ sudo systemctl stop ipfs-daemon.service
$ ./uninstall
Uninstall IPFS? [Y/n] Y
>>> Uninstalling IPFS
Uninstall IPFS directory (/home/pi/.ipfs)? This will remove all your local IPFS files. [Y/n] n
>>> All done.

2. Upgrades should now work out of the box (no need to run the migration manually).

[RMBLRX]

Sorry, I only just circled back to this, but I forgot to specify that this was on an Udoo Quad, running Udoobuntu. I noticed that Ubuntu was still somewhat untested.

As an aside, I was also curious whether you knew anything about the memory leak in IPFS as it applies to these sorts of devices, as I've had trouble with both that Udoo Quad, my pi1B, and my pi3B+ running out of memory and freezing up within the course of a day, even with just a couple of static sites pinned (I doubt that even makes a difference). I guess I'm wondering because, if the problem's ubiquitous to these sorts of devices, maybe there's some configuration that a script like this could automate.