arrpc: 3.4.0 -> 3.5.0; add systemd user service

[UlyssesZh]

Using tagged releases as OpenAsar/arrpc#48 is resolved now.

Added a systemd user service.

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 24.11 Release Notes (or backporting 23.11 and 24.05 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

---

Add a 👍 reaction to pull requests you find important.

[NotAShelf]

I'm not sure if this is standard practice, would be the first time I see this in nixpkgs.

[UlyssesZh]

I think it is standard. Packages like thunar and syncthing all installs a service file there. Example:

nixpkgs/pkgs/desktops/xfce/core/thunar/wrapper.nix

Lines 22 to 31 in c08e797

	# point to wrapped binary in all service files
	for file in "lib/systemd/user/thunar.service" \
	"share/dbus-1/services/org.xfce.FileManager.service" \
	"share/dbus-1/services/org.xfce.Thunar.FileManager1.service" \
	"share/dbus-1/services/org.xfce.Thunar.service"
	do
	rm -f "$out/$file"
	substitute "${thunar}/$file" "$out/$file" \
	--replace "${thunar}" "$out"
	done

It will be picked up by system if config.systemd.packages includes the package. My concern is whether it should be a system unit or a user unit.

[NotAShelf]

The example you've provided is for vendoring a service provided by upstream - not for shipping our own, though I can't exactly see an issue with it...

I am in favor of having it as an user service, since that's already what the home-manager module does

[UlyssesZh]

Alright it seems that I am wrong. I need to define a nixos module for that.

[UlyssesZh]

https://discourse.nixos.org/t/how-to-enable-upstream-systemd-user-services-declaratively/7649

Honestly I still don't quite understand how systemd user services provided by packages work in NixOS. There are some discussions.

[NotAShelf]

Please separate formatting and package change commits.

[UlyssesZh]

@NotAShelf @Anomalocaridid It seems that running arrpc for a while (like some minutes) makes it un-killable even with kill -9. This makes the computer stuck at shutting down, which is pretty bad. Could you see whether you can reproduce the bug? I cannot find an issue for that in the upstream, but I am suspecting that this is a bug of newer Node versions.

[NotAShelf]

I've been running arrpc for a while now, with relative success (if you don't count the CPU spike after a few hours) Is this bug exclusive to 3.5.0? Or does it exist on older versions as well?

[UlyssesZh]

It exists on 3.4.0, too. It only happened after I upgraded my NixOS 24.05 channel on Oct 24. Could you please try the master branch of nixpkgs?

[UlyssesZh]

On my laptop, cloning the arrpc repo main branch and run npm i && node src (with Node 20.15 from NixOS 24.05) reproduces this bug.

[NotAShelf]

Okay, built from master and started it in the background. I'll leave it running for a while.

[NotAShelf]

result/bin/arrpc 
[arRPC] arRPC v3.4.0
[arRPC > bridge] listening on 1337
[arRPC > ipc] listening at /run/user/1000/discord-ipc-0
[arRPC > websocket] 6463 in use!
[arRPC > websocket] listening on 6464
[arRPC > process] started
zsh: killed     result/bin/arrpc

after 10 minutes of runtime, killed with kill -9 <pid>

[UlyssesZh]

That's strange. Could you try my branch in the PR?

[UlyssesZh]

This is getting increasingly strange. If I use an older generation built before I updated on Oct 24, the bug doesn't appear, even if I run the exact same result/bin/arrpc.

[NotAShelf]

Also works from your branch.

[UlyssesZh]

Could you share your nix-info -m? I can steadily reproduce this bug. Here is mine:

• system: "x86_64-linux"
• host os: Linux 6.6.58, NixOS, 24.05 (Uakari), 24.05.5993.cd3e8833d706
• multi-user?: yes
• sandbox: yes
• version: nix-env (Nix) 2.18.8
• channels(root): "nixos-24.05, nixos-hardware, nixos-unstable"
• nixpkgs: /nix/var/nix/profiles/per-user/root/channels/nixos

This Linux kernel shouldn't matter because I tried both 6.1 and 6.6 (I cannot try newer kernels because nvidia-x11 fails to build).

If you are also using the nixos-24.05 channel, could you try upgrading it? Sorry for bothering.

[NotAShelf]

Mine is similar to yours, though I'm running

1. Lix
2. nixos-unstable (24.11)

I believe we have already established that your branch does build and run fine, as well as current master. This is likely an issue on your end.

[UlyssesZh]

After bisecting, I found that f142a76 (linux_6_6: 6.6.56 -> 6.6.57) (if I use kernel 6.6) or 0dffe83 (linux_6_1: 6.1.112 -> 6.1.113) (if I use kernel 6.1) is the problematic commit. @NotAShelf Could you please tell me your kernel version?

[NotAShelf]

Currently 6.12-rc5, I was running 6.11.5 at the time of my previous tests.

[UlyssesZh]

Sadly I cannot use kernel 6.11 because nvidia-x11 fails to build.

Opened OpenAsar/arrpc#120.