Electron-updater: Appimage linux updater fails with ENOSYS: function not implemented

[JustTNE]

• Version: 4.1.2 (electron-updater)

• Target: Linux Appimage, Manjaro Linux

Electron updater errors out with the following logs:

Checking for update...
Found version 1.1.70727281 (url: sag-electron-1.1.70727281.AppImage)
Update available.
Downloading update from sag-electron-1.1.70727281.AppImage
updater cache dir: /home/elite/.cache/sag-electron-updater
Update has already been downloaded to /home/elite/.cache/sag-electron-updater/pending/sag-electron-1.1.70727281.AppImage).
Update downloaded; will install in 1 seconds
Auto install update on quit
Install: isSilent: true, isForceRunAfter: false
Error: Error: ENOSYS: function not implemented, unlink '/run/user/1000/appimagelauncherfs/0001.AppImage'
    at Object.unlinkSync (fs.js:1008:3)
    at AppImageUpdater.doInstall (/tmp/.mount_sag-elLEvSvQ/resources/app.asar/node_modules/electron-updater/out/AppImageUpdater.js:144:9)
    at AppImageUpdater.install (/tmp/.mount_sag-elLEvSvQ/resources/app.asar/node_modules/electron-updater/out/BaseUpdater.js:71:19)
    at /tmp/.mount_sag-elLEvSvQ/resources/app.asar/node_modules/electron-updater/out/BaseUpdater.js:104:12
    at App.<anonymous> (/tmp/.mount_sag-elLEvSvQ/resources/app.asar/node_modules/electron-updater/out/ElectronAppAdapter.js:60:48)
    at Object.onceWrapper (events.js:282:20)
    at App.emit (events.js:199:15)
    at App.<anonymous> (/tmp/.mount_sag-elLEvSvQ/resources/app.asar/main.js:41:42)
    at App.emit (events.js:199:15)

What's interesting to note here is that /run/user/1000/appimagelauncherfs/ contains copies of appimages that are currently running. The error log implies that process.env.APPIMAGE does not return the path where the file was started from (by the user). I suspect that this is an issue with AppImageLauncher, which is the default method of integrating and running appimages on a lot of systems. This could easily be solved if there was some way of knowing what directory the appimage was actually started from.

Package.json: https://gitlab.com/nullworks/accgen/accgen-electron-app/blob/CD/package.json
Node ver: v11.15.0
Npm ver: 6.10.0

[Ashesh3]

I'm having the same issue.

[dextronox]

Yep, same issue.

[AhMyth]

same here

[143mailliw]

Same issue on arch.

[JustTNE]

@develar Any chance we could get some input from you here? I'd be willing to contribute, but I have no clue how to get the actual appimage path as of right now.

[mcous]

I came up with a very dirty workaround that I'm not going to ship to my users because it feels way too brittle. I think until this is resolved I have to warn my users to not use AppImageLauncher

Anyway, when AppImageLauncher has launched an app, it sets the environment variable DESKTOPINTEGRATION to AppImageLauncher, so we can know if the AppImage was launched via AppImageLauncher.

Additionally, the environment variable ARGV0 seems to be set to the path to the source AppImage in ~/Applications. So, I've had a successful auto-update if I insert this piece of code before running electron-updater:

// HACK(mc, 2019-09-10): work around https://github.com/electron-userland/electron-builder/issues/4046
if (process.env.DESKTOPINTEGRATION === 'AppImageLauncher') {
  // remap temporary running AppImage to actual source
  // THIS IS PROBABLY SUPER BRITTLE AND MAKES ME WANT TO STOP USING APPIMAGE
  updater.logger.info('rewriting $APPIMAGE', {
    oldValue: process.env.APPIMAGE,
    newValue: process.env.ARGV0,
  })
  process.env.APPIMAGE = process.env.ARGV0
} else {
  updater.logger.info('Not running in AppImageLauncher')
}

I am categorically not going to ship this to users but your risk-tolerance may be different than mine

[JustTNE]

If ARGV0 is consistent, then this can easily be up-streamed into electron builder.

[ozooner]

@mcous - Thanks for posting the workaround. I guess the long-term solution is probably to start using the AppImageUpdate utility instead to provide updates to end users. I am not happy about it either as we have (had) a perfectly working system...

I don't think that the ARGV0 is as brittle solution as you think. I would probably only do the swap right before installing the update. Looking through the code, it seems to be used by the AppImageLauncher quite explicitly as well, so I think it's here to stay.

Looking for argv[0] I came across a function that checks the file for updates. So one midway approach could also be to ditch the electron-updater and simply download the file to the AppImage's location and have the AppImageLauncher to take care of detecting the change and re-launching the app.

There's also the option of asking users to uninstall appimagelauncher ;)

[ozooner]

Okay, so for my use-case it's important that the update process is autonomous. By default the update process would create a new file in the Applications directory and execute it. This would prompt the user for 'integrate' or 'run once' dialog. I am not using version in the file name, so that electron-updater would overwrite the file so that the prompt wouldn't pop up. This works, however the appimagelauncher will still run the old version (from a cache somewhere), though the file itself has updated. I even went so far to manually replace the .AppImage with a different file in the Applications folder, and renamed the new AppImage exactly the same as previously 'integrated' one. It still runs the old version...

[stale]

Is this still relevant? If so, what is blocking it? Is there anything you can do to help move it forward?

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[mcous]

I believe this issue is still relevant. AppImageLauncher is recommended by electron-builder for desktop integration, but electron-updater does not work with AppImageLauncher installed AppImages

I had this issue on Arch for almost half a year, it was never fixed, I did a new clean Arch reinstall and only that fixed it.

[TheAssassin]

Indeed this is more of an issue with Electron's updater than AppImageLauncher, this problem has been fixed in AppImageUpdate itself IIRC. Basically, the issue disappears if you don't use AppImageLauncher.

Right now there's nothing we can do in AppImageLauncher to help fix this issue, Electron's updater needs to implement a tiny workaround. @develar I'd like to help get this fixed, please feel free to ping me.