Arch Linux User Repository

Linux kernels >= v6.9-arch1 have a bug that prevents the server running and the AUR package being built. Downgrade to v6.8.9-arch1 or use linux-lts.

Ah, thanks for the greater detail.

I'm happy to stick with the nodejs-lts-*. And just as a data point, I was using linux-lts already. :shrug: I did just try using nodejs v21 and it also failed there. So to summarize, nodejs v21 and v22 both on linux-lts failed for me. It's working great on nodejs-lts-iron and linux-lts.

I emphasize "for me" because I'm not an expert on nodejs nor arch-nspawn, so again, just an fyi. Probably something silly I messed up. :) I appreciate your effort on maintaining this package for us!

Linux kernels >= v6.9-arch1 have a bug that prevents the server running and the AUR package being built. Downgrade to v6.8.9-arch1 or use linux-lts.

@feinedsquirrel thanks for this. I had noticed the same yesterday but failed to find root cause until now. It is not actually the nodejs version (I thought the same initially) but the kernel version. The server stops working and build fails for the same reason - both generating Internal Error: spawn ETXTBSY error. This can be seen in journalctl -b -u actual-server.service and in the yarn build log (/tmp/xfs-eb807551/build.log in your example).

Kernel v6.9-arch1 appears to introduce a bug as reported here. The offending commit confirmed between v6.8.9-arch1 and v6.9-arch1 in the archlinux/linux github.

git --no-pager log --pretty=oneline v6.8.9-arch1..v6.9-arch1 | grep af5d68
af5d68f8892f8ee8f137648b79ceb2abc153a19b io_uring/sqpoll: manage task_work privately

Either downgrade to kernel v6.8.9 or use linux-lts for now.

(Note that I've had separate problems building with nodejs and generally use nodejs-lts-hydrogen since that's what the upstream docker image uses. It doesn't surprise me that you've found nodejs-lts-iron works too but I haven't tested yet.)

I noticed my server was no longer online, and found your note below about the nodejs version not matching. I have the plain nodejs installed to my system, and am using a clean chroot. I'm getting the following error(s).

==> Starting build()...
➤ YN0000: Successfully set enableTelemetry to false
➤ YN0000: · Yarn 4.0.1
➤ YN0000: ┌ Resolution step
➤ YN0000: └ Completed
➤ YN0000: ┌ Post-resolution validation
➤ YN0002: │ actual-sync@workspace:. doesn't provide @babel/core (pd13b1), requested by @babel/preset-typescript.
➤ YN0086: │ Some peer dependencies are incorrectly met; run yarn explain peer-requirements <hash> for details, where <hash> is the six-letter p-prefixed code.
➤ YN0000: └ Completed
➤ YN0000: ┌ Fetch step
➤ YN0013: │ 629 packages were added to the project (+ 237.82 MiB).
➤ YN0000: └ Completed in 3s 50ms
➤ YN0000: ┌ Link step
➤ YN0007: │ bcrypt@npm:5.1.0 must be built because it never has been before or the last one failed
➤ YN0007: │ better-sqlite3@npm:9.1.1 must be built because it never has been before or the last one failed
➤ YN0009: │ better-sqlite3@npm:9.1.1 couldn't be built successfully (exit code 1, logs can be found here: /tmp/xfs-eb807551/build.log)
➤ YN0000: └ Completed in 1s 698ms
➤ YN0000: · Failed with errors in 4s 860ms
==> ERROR: A failure occurred in build().
    Aborting...

I found this: https://github.com/actualbudget/actual-server/pull/357 which references node-abi complaints in https://github.com/actualbudget/actual/pull/2763

But I'm not entirely convinced that is the issue, because even checking out the previous PKGBUILD (24.4), I cannot build successfully from source in a clean chroot.

Any ideas appreciated

EDIT: I installed nodejs-lts-iron into the chroot and it successfully built 24.5.0-1.

Could be that actual server is not compatible with nodejs 22. I am not sure how long ago the server stopped syncing for me. I don't use it super frequently. I checked just now and it looks like the Arch package for nodejs went from 21.x to 22.x a few weeks ago.

@tronicdude apologies the supplied service file is missing the [Install] section. I missed this because my own installation pulls the service in through a Wants= relationship to another unit. You can start the service manually but it cannot be enabled, i.e. started automatically at boot:

systemctl start actual.service

I will correct the service file now to add the missing section, keep an eye out for 24.1.0-4.

@emphire the package dependency is nodejs allowing any version to be installed, i.e. any packaged that provides nodejs. However you must build the package with the same version you have installed on your target machine - or you will receive errors such as this. This is most commonly a problem with a clean chroot where it is easy to let nodejs to be installed to the chroot (v21 in the repos at the moment) but if you have a different version, e.g. nodejs-lts-hydrogen installed (v18) on your target machine then it will not run. If using a clean chroot, you must manually install the desired provider of nodejs first before building the package.

> sudo systemctl enable --now actual-server
The unit files have no installation config (WantedBy=, RequiredBy=, UpheldBy=,
Also=, or Alias= settings in the [Install] section, and DefaultInstance= for
template units). This means they are not meant to be enabled or disabled using systemctl.

Possible reasons for having these kinds of units are:
• A unit may be statically enabled by being symlinked from another unit's
  .wants/, .requires/, or .upholds/ directory.
• A unit's purpose may be to act as a helper for some other unit which has
  a requirement dependency on it.
• A unit may be started when needed via activation (socket, path, timer,
  D-Bus, udev, scripted systemctl call, ...).
• In case of template units, the unit is meant to be enabled with some
  instance name specified.

Not exactly sure how to start this thing

I'm getting the following error when attempting to start the server:

 Started Actual Server.
]: Checking if there are any migrations to run for direction "up"...
]: Rejection: Error: The module '/usr/share/webapps/actual-server/node_modules/better-sqlite3/build/Release/better_sqlite3.node'
]: was compiled against a different Node.js version using
]: NODE_MODULE_VERSION 115. This version of Node.js requires
]: NODE_MODULE_VERSION 108. Please try re-compiling or re-installing
]: the module (for instance, using `npm rebuild` or `npm install`).
]:     at Module._extensions..node (node:internal/modules/cjs/loader:1340:18)
]:     at Module.load (node:internal/modules/cjs/loader:1119:32)
]:     at Module._load (node:internal/modules/cjs/loader:960:12)
]:     at Module.require (node:internal/modules/cjs/loader:1143:19)
]:     at require (node:internal/modules/cjs/helpers:119:18)
]:     at bindings (/usr/share/webapps/actual-server/node_modules/bindings/bindings.js:112:48)
]:     at new Database (/usr/share/webapps/actual-server/node_modules/better-sqlite3/lib/database.js:48:64)
]:     at openDatabase (file:///usr/share/webapps/actual-server/src/db.js:57:30)
]:     at getAccountDb (file:///usr/share/webapps/actual-server/src/account-db.js:12:18)
]:     at Migration.up (file:///usr/share/webapps/actual-server/migrations/1694360479680-create-account-db.js:4:9) {
]:   code: 'ERR_DLOPEN_FAILED'
]: }
 actual-server.service: Deactivated successfully.
 actual-server.service: Consumed 1.148s CPU time.

updated to depend on nodejs and bumped to latest upstream.

Thanks @zachasme for pointing this out. I couldn't get this to build with nodejs v20 in a clean chroot which is why I limited it to nodejs-lts-hydrogen. I'll look into it though because it works outside a chroot.