Quick question, but why is the linux installer a binary, rather than a far more traditional shell script?
Installation has failed at some step after everything was copied and this way I cannot check why it failed on our system. Normally I’d just inspect the script and either fix our environment or edit it, as appropriate.
With both the installer and uninstaller being binaries, it’s all a bit black box.
@AlkisFortuneFish , we use a single unified installer for all platforms to simplify development. Even if we had used a script, the Accelerator itself is also a compiled binary. We don’t offer it as open source. What were you hoping to learn from inspecting the installation sequence?
So are the vast majority of daemons running on my system, they still don’t have binary installers.
What it writes and where. It’s more troubleshooting than learning, it’s a pretty standard thing when working on any Unix platform.
Right now, installation fails on our Debian 9 dev ops server, with permission denied when attempting to register the daemon, after it has already copied it into the installation directory (currently /opt/Unity/accelerator), even though I am running the installer as root. A quick glance shows that unity-accelerator has 0644 permissions, so it obviously cannot be executed.
If I could check what the installer runs immediately afterwards, I could fix the permissions and then manually run the rest of it, or just fix the script itself. As it stands, I can do exactly nothing.
Yep, I 100% understand–I’m a very big Bash fan (to the point of overuse; case in point: Shortyk8s). However, when working on cross platform products like the Accelerator, we want to focus more on the product and less on how it’s installed.
I’d be happy to help troubleshoot why it might be failing on Debian. Feel free to private-message me with any other details you feel comfortable sharing, like any logs from /tmp/unity-accelerator*, the exact version of Debian you’re using (e.g. lsb_release -a), the full output of what you see during the installation, etc. The Accelerator is built only for amd64 platforms using the standard glibc, for example.
Actually no need! I spun up a Debian stretch container locally, and sure enough, I see the same error:
Error running /opt/Unity/accelerator/unity-accelerator unregister -persist
“/root/.config/unity-accelerator” legacy: /bin/sh: 1:
/opt/Unity/accelerator/unity-accelerator: Permission denied
We’ll fix this up and get it published asap. Thanks for letting us know!
Oh, cool. Was in a meeting when you sent the first reply! 
Turns out it was a silly packaging error and affected all Linux installs! It’s been fixed, so if you redownload and run it again, this should be avoided. I’d recommend first running the /opt/Unity/accelerator/uninstall to start from a fresh state.
Thanks! I’ll have a play on Monday when I get back to the office.
We’re currently using the cache server on a Synology Diskstation NAS. Will try if the new binary packaging will affect this.