This topic was closed, but the issue still exists.
I have only been able to get offline-install to work once, when a minor upgrade of a logstash-input-beats was done.
Where it is a big jump and lots of dependencies involved, the method fails and I have tried all sorts of workarounds to make it work.
This particular topic mentioned zipping the whole logstash directory and transferring this from staging to production machine as a method.
After much frustration, I ended up taking this approach.
Rather than zipping up the entire logstash directory on the staging machine, I took a copy of the original directory, and then compared the upgraded directory to the original with diff.
diff -qrN ${ORIGINAL_DIR} ${UPGRADED_DIR} | sed -e 's/.(/usr.)\sdiffer/\1/' > ${DIFF_FILE}
tar -zcf /tmp/${PACKAGE_FILE} --files-from ${DIFF_FILE} > /dev/null 2>&1
I transfer this (much smaller: 23MB vs 112MB) archive and unzip over the top of the installed files.
The question to other logstash users or devs out there:
Are there any un-intended consequences of doing my offline upgrades this way?
My justification for this, is that my staging machine is in the same state as the production machine, and therefore any gemfile files and other plugin and ruby files will be correct and in-sync.
Another thing to note: if logstash is installed via a distro package (i use Ubuntu debs), then when removing the package, not all directories will be cleaned up due to additional files present that were not present in the original package. These will need to be manually cleaned if you want to ensure your logstash is installed in the correct state. This would be the case whether the prepare-offline-pack method was used, or the method I have described above.
Any recommendations would be appreciated.
Note: I am on logstash 5.4.0, and its not possible to upgrade the whole package as it would require major retesting. I am simply upgrading the logstash-input-beats plugin to workaround the Slow FD leak which has impacted my system.