Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
JustTNE opened this issue Jul 12, 2019 · 33 comments
Labels

Comments

@JustTNE
Copy link

JustTNE commented Jul 12, 2019

  • 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
Copy link

Ashesh3 commented Jul 12, 2019

I'm having the same issue.

@dextronox
Copy link

Yep, same issue.

@AhMyth
Copy link

AhMyth commented Jul 28, 2019

same here

@143mailliw
Copy link

Same issue on arch.

@JustTNE
Copy link
Author

JustTNE commented Jul 31, 2019

@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
Copy link

mcous commented Sep 11, 2019

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
Copy link
Author

JustTNE commented Sep 17, 2019

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

@ozooner
Copy link

ozooner commented Nov 10, 2019

@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
Copy link

ozooner commented Nov 11, 2019

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
Copy link

stale bot commented Jan 10, 2020

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.

@stale stale bot added the backlog label Jan 10, 2020
@mcous
Copy link

mcous commented Jan 10, 2020

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

@stale stale bot removed the backlog label Jan 10, 2020
@ghost
Copy link

ghost commented Jan 11, 2020

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
Copy link

TheAssassin commented Feb 6, 2020

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.

@Finn0811
Copy link

Finn0811 commented Feb 6, 2020

I have the same issue now. Looking forward for a fix.

@quanglam2807
Copy link
Contributor

@mcous @ozooner Thank you very much for helping! So in conclusion, is the workaround by @mcous production-ready?

@dsafreno
Copy link

I'm running into the same issue, also from a user on Manjaro Linux. FWIW.

@mcous
Copy link

mcous commented May 12, 2020

@quanglam2807 my company does not use that workaround in production, so I cannot vouch for it. We currently tell our users that they should not use AppImageLauncher

@quanglam2807
Copy link
Contributor

quanglam2807 commented May 12, 2020

@quanglam2807 my company does not use that workaround in production, so I cannot vouch for it. We currently tell our users that they should not use AppImageLauncher

Thank you for the clarification! I couldn’t wait for your answer so I decided to use it anyway in production. But luckily, I haven’t heard any complains.

@ozooner
Copy link

ozooner commented May 15, 2020

I could not get this workaround to work properly, it could be because I had an additional requirement that the updated AppImage should have the same filename as before. What happened in that case was that the file was overwritten with a new file, however when launched, it still launched the old version of the app from some AppImage cache/storage.

After spending half a day on the issue I also gave up and concluded this is not something we can work around from inside our app (or the solution would be too hacky). We detect the AppImageLauncher and advise our users to uninstall it if they want automatic updates to work properly.

if(process.env.DESKTOPINTEGRATION === 'AppImageLauncher'){...}

For users that did not uninstall AppImageLauncher we simply don't install updates to keep their current version running without the errors.

@TheAssassin
Copy link

It's sad to see zero reaction from the electron builder team. I'm not a fan reading when people (have to?) recommend users to uninstall AppImageLauncher entirely for some auto-update (which I'm not a fan of) or general updates to work as intended. If there were a workaround I could implement, that'd be no problem, but it's really not that hard to fix the problem in the Electron updater itself.

The AppImage type 3 currently discussed here fixes the need for AppImageLauncher to ship with a custom FUSE filesystem which could cause trouble. binfmt_misc is to blame here, too.

@ozooner @mcous please recommend your users AppImageLauncher Lite instead of uninstalling AppImageLauncher entirely. The Lite version is not affected by this bug. And it provides at least some better desktop integration.

@JustTNE
Copy link
Author

JustTNE commented May 25, 2020

@TheAssassin would you recommend users (of electron-builder) to set X-AppImage-Integrate=false in the .desktop file for now? I've been forced to do that for one of my other apps (not electron) because my self updating appimage is not working well with appimagelauncher.

@TheAssassin
Copy link

No, that would not solve the issue at all. Neither does uninstalling, it's basically just a baaaad hack.

@stale
Copy link

stale bot commented Jul 25, 2020

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.

@stale stale bot added the backlog label Jul 25, 2020
@quanglam2807
Copy link
Contributor

Not stale, bot.

@stale stale bot removed the backlog label Jul 25, 2020
@abdurrahmanyildirim
Copy link

Any update?

@abdurrahmanyildirim
Copy link

abdurrahmanyildirim commented Aug 7, 2020

this solution #4046 (comment) works for me but you should include it inside of update-downloaded event otherwise users cant see update progress. If you dont use it in update-download event, it works so fast or doesnt work well

autoUpdater.on('update-downloaded', () => {
   if(process.env.DESKTOPINTEGRATION === 'AppImageLauncher') {
     process.env.APPIMAGE = process.env.ARGV0;
   }
})

charodziej added a commit to chariguanaCode/competitive-debugging-system that referenced this issue Sep 3, 2020
 * workaround for issue electron-userland/electron-builder#4046
   with automatic updates under Linux with AppImageLauncher
@TheAssassin
Copy link

TheAssassin commented Sep 28, 2020

Should be resolved once the upcoming release of AppImageLauncher has been published. It replaces the FUSE filesystem with a (hopefully) more robust solution. See TheAssassin/AppImageLauncher#361 for more information. No need for additional workarounds.

Looking for testers of the new method! Please report feedback in TheAssassin/AppImageLauncher#361.

Edit: tried two AppImages (one of them is Jitsi Meet), the update worked as intended. Still not a fan of the custom method (would prefer an integration with AppImageUpdate), but it works now.

@adam-lynch
Copy link
Contributor

adam-lynch commented Oct 20, 2020

The AppImageLauncher fix was released. I tried it and it worked fine for me. This could be closed?

@ozooner
Copy link

ozooner commented Oct 20, 2020

@adam-lynch do you know which version contains the fix?

@adam-lynch
Copy link
Contributor

@ozooner 2.2.0, see TheAssassin/AppImageLauncher#361

@stale
Copy link

stale bot commented Dec 19, 2020

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.

@stale stale bot added the backlog label Dec 19, 2020
@stale stale bot closed this as completed Dec 26, 2020
@PaluMacil
Copy link

This was still happening with uninstall and reinstall for me for the last 15 months till today. Finally today I noticed that the latest/edge channel that I was on hasn't been updated since the problem started. latest/stable has the actual latest version. I uninstalled and then switched channels and reinstalled. I guess next time there is an update I'll know if this is still broken or if it can update now. If you're reading this, make sure you switch to latest/stable since if you were on edge to try to get the fix faster, you were stuck on an old version.

@PaluMacil
Copy link

hm, maybe I am remembering how this bug worked wrong... it looks like I'm using snap now, not appimage, and this bug was for app image. I must have switched in my attempt to get it working and long forgot. Regardless, you do need the latest/stable channel for snap or you'll be stuck on the broken version.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests