Crash on first page access: "AbsolutePaths - Could not identity Etherpad base path..."

[risacher]

Describe the bug With a fresh install from github of v 1.9.1 usins Sqlite3 as datastore, the server starts, but on first page access exits with this message:

[2023-07-12 14:01:14.032] [ERROR] AbsolutePaths - Could not identity Etherpad base path in this linux installation in "/home/magnus/etherpad-lite/src/node_modules/ep_etherpad-lite"

To Reproduce Steps to reproduce the behavior:

1. git clone https://github.com/ether/etherpad-lite.git
2. Customize settings.json. Note I am using sqlite3 backend and accessing etherpad-lite behind a reverse proxy.
3. Install sqlite3 by doing: cd src; npm i sqlite3
4. cd ~/etherpad-lite; sh src/bin/run.sh
5. Access a pad at https://myserver/pad/p/pagename (this worked on my old install)
6. etherpad-lite server crashes with error message shown above.

Expected behavior etherpad-lite serves out page like it used to before I tried to upgrade to 1.9.1.

Screenshots If applicable, add screenshots to help explain your problem.

Server (please complete the following information):

• Etherpad version: 1.9.1
• OS: [e.g., Ubuntu 20.04.6 LTS
• Node.js version (node --version): v16.20.1
• npm version (npm --version): 8.19.4 (although when the server starts, it says (npm --version: 6.14.18)
• Is the server free of plugins: Yes - fresh install from git.

Desktop (please complete the following information):

• OS: MacOS 12.6.6
• Browser: Chrome
• Version 114.0.5735.198

Additional context Add any other context about the problem here.

I'm using sqlite3 for data storage and do have an old database from previous install, and the server does run behind a reverse-proxy.

[risacher]

In my install, this error message appears in two files: src/node/utils/AbsolutePaths.js and src/node_modules/ep_etherpad-lite/node/utils/AbsolutePaths.js. I confirmed that both versions of this code are executed at different times, and the version in src/node/utils/ works fine. The first version runs in /home/magnus/etherpad-lite/src and returns /home/magnus/etherpad-lite as expected. The second version runs in/home/magnus/etherpad-lite/src/node_modules/ep_etherpad-lite and it fails.

[webzwo0i]

Please try running npm with --no-save, e.g.

rm -rf src/node_modules ./node_modules
git checkout node_modules # to regenerate a symlink
npm i sqlite3 --no-save # in the root directory
sh src/bin/run.sh

[risacher]

If I add this code to src/node_modules/ep_etherpad-lite/node/utils/AbsolutePaths.js...:

  if (maybeEtherpadRoot === false) {
    /*
     * Temporary workaround
     */
    maybeEtherpadRoot = popIfEndsWith(splitFoundRoot, ['src', 'node_modules', 'ep_etherpad-lite']);
  }

...and then run the server with node src/node/server.js, the problem is fixed. But running sh src/bin/run.sh breaks it again, because it runs src/bin/installDeps.sh which fetches a clean copy of the code without the workaround. This work-around does not address the underlying design issue of why there are two copies of AbsolutePaths.js in the first place and why this issue breaks on Ubuntu 20.04 but not on whatever setup the core team is working on.

[risacher]

@webzwo0i Attaching the transcript of your suggestion. Summary: did not work. transcript.txt

[webzwo0i]

Can you run git status and if there is any change in package.json or package-lock.json from your old attempts, revert to the original version, e.g. git checkout src/package*

The second etherpad, that you see in src/node_modules/ep_etherpad-lite is an older version and should not exist. I think it slips in because src/package.json is changed when you use npm i without --no-save. I'm not 100% sure about the internals, though. Actually it's pulled in as a devDependency via etherpad-cli-client, so the problem might not appear if you run export ETHERPAD_PRODUCTION=true before sh src/bin/run.sh but I'm not sure either.

[webzwo0i]

If you want and have the time, you could even check out my branch at https://github.com/ether/etherpad-lite/pull/5812 It's called fix-admintests, but the name is misleading, it should be fix-npm. It gets rid of the the old npm version that you saw and works one my machine and some others, however some report it does not work on their machine...

rm -rf src/node_modules ./node_modules package* src/package*
git checkout src node_modules
git checkout fix-admintests
npm i sqlite3 # you don't need --no-save anymore
sh src/bin/run.sh

[risacher]

My package.json and package-lock.json were different, so per your suggestion I re-checkout'd them, but the outcome was not substantively different.
transcript2.txt

Also tried to checkout the fix-admintests branch, but I get this (which seems to be an unrelated issue):

magnus@cedar:~/etherpad-lite$ sh src/bin/run.sh
npm WARN config production Use `--omit=dev` instead.
Removing src/node_modules.
Linking src as new package ep_etherpad-lite.
npm WARN config production Use `--omit=dev` instead.
npm ERR! code EACCES
npm ERR! syscall symlink
npm ERR! path ../../../../home/magnus/etherpad-lite/src
npm ERR! dest /usr/local/lib/node_modules/ep_etherpad-lite
npm ERR! errno -13
npm ERR! Error: EACCES: permission denied, symlink '../../../../home/magnus/etherpad-lite/src' -> '/usr/local/lib/node_modules/ep_etherpad-lite'
npm ERR!  [Error: EACCES: permission denied, symlink '../../../../home/magnus/etherpad-lite/src' -> '/usr/local/lib/node_modules/ep_etherpad-lite'] {
npm ERR!   errno: -13,
npm ERR!   code: 'EACCES',
npm ERR!   syscall: 'symlink',
npm ERR!   path: '../../../../home/magnus/etherpad-lite/src',
npm ERR!   dest: '/usr/local/lib/node_modules/ep_etherpad-lite'
npm ERR! }
npm ERR!
npm ERR! The operation was rejected by your operating system.
npm ERR! It is likely you do not have the permissions to access this file as the current user
npm ERR!
npm ERR! If you believe this might be a permissions issue, please double-check the
npm ERR! permissions of the file and its containing directories, or try running
npm ERR! the command again as root/Administrator.

[risacher]

For what it's worth, I went back to 'master', and ran with ETHERPAD_PRODUCTION=true, and I think the problem I saw does not occur. I'd been flailing a bit though, so I deleted everything and started with a fresh pull from github, and with ETHERPAD_PRODUCTION=true problem did not occur.

I further note that when running in this way, src/node_modules/ep_etherpad-lite does not exist.

[risacher]

Any thoughts from y'all core team members on how you would like to fix this in the interim, while the fix-admintests branch works out the longer term fix? I'm happy to work up a PR with a hint of direction. Maybe run.sh & safeRun.sh should default to ETHERPAD_PRODUCTION=true for now? (I don't know how widespread the problem is. Does it just effect Ubuntu 20.04, or node 16.20.1?, &c.)

[heyLu]

I don't know how widespread the problem is. Does it just effect Ubuntu 20.04, or node 16.20.1?, &c.

I also experienced this on Archlinux with Nodejs 20.4.0, so I would expect this to be more widespread. (I had no time to test with ETHERPAD_PRODUCTION=true or the fix-admintests branch yet, but I would also expect that the fixes described above will work on my system as well.)

[SamTV12345]

Any thoughts from y'all core team members on how you would like to fix this in the interim, while the fix-admintests branch works out the longer term fix? I'm happy to work up a PR with a hint of direction. Maybe run.sh & safeRun.sh should default to ETHERPAD_PRODUCTION=true for now? (I don't know how widespread the problem is. Does it just effect Ubuntu 20.04, or node 16.20.1?, &c.)

I had this problem when using an up to date npm. You need to use [email protected] or equal otherwise it might happen that the package-lock.json is updated to v3 and it seems to break a lot. There is an open pull request for updating to the latest npm #5812

So it is best to start from scratch. Download the version 6 of npm and just use ./src/bin/run.sh to start the etherpad server.

This is also confirmed by the output in the transcript

[SamTV12345]

In #5735 we could solve this issue in docker. So maybe you can transfer the solution to your bare metal installation.

[SamTV12345]

@risacher If the issue is solved, please report back as we want to have a better overview of still open issues.

[risacher]

@SamTV12345 I believe this issue is still valid. While there are some work-arounds in the thread (such as running ETHERPAD_PRODUCTION=true) the code is basically still broken in HEAD. I believe that #5812 will probably fix this when it's finished, so I don't think it's worth working on this directly, but the issue hasn't been resolved.

[SamTV12345]

@SamTV12345 I believe this issue is still valid. While there are some work-arounds in the thread (such as running ETHERPAD_PRODUCTION=true) the code is basically still broken in HEAD. I believe that #5812 will probably fix this when it's finished, so I don't think it's worth working on this directly, but the issue hasn't been resolved.

As mentioned before Etherpad only runs when using npm@6. This needs to be globally installed with the -g flag. This is due to change in dependency resolution causing the message in the title. @webzwo0i is working on this issue but is currently afk. So I can't really promise when this issue is resolved. We came to the conclusion that this will be pushed out with the next release hopefully - if everything goes by plan.

[risacher]

For the benefit of anyone else running into this issue, I was able to install sqlite3 (actually better-sqlite3, which is needed since v1.9.2) without downgrading npm globally and without my system npm (v8.19.4) upgrading the version of src/package-lock.json by doing this: cd src; npx npm@v6 install better-sqlite3

I still consider this a work-around that will hopefully be fixed someday, maybe by #5812.

[SamTV12345]

We can finally close this issue. Everything solved in Etherpad 2.