Cursor trying to start a SystemD service

Support Help
,
1

I run Cursor in Linux under a pretty relaxed Apparmor sandbox that stops processes from using SystemD and bypassing the sandbox. In the last cursor update, I now get this warning from D-Bus:

\[53194:0125/231050.359242:ERROR:dbus/object_proxy.cc:573\] Failed to call method: org.freedesktop.systemd1.Manager.StartTransientUnit: object_path= /org/freedesktop/systemd1: org.freedesktop.DBus.Error.AccessDenied: An AppArmor policy prevents this sender from sending this message to this recipient; type=“method_call”, sender=“:1.189” (uid=1000 pid=53194 comm=“cursor --no-sandbox” label=“cursor (enforce)”) interface=“org.freedesktop.systemd1.Manager” member=“StartTransientUnit” error name=“(unset)” requested_reply=“0” destination=“org.freedesktop.systemd1” (uid=1000 pid=3653 comm=“/usr/lib/systemd/systemd --user” label=“unconfined”)

with the body

(“app-org.chromium.Chromium-53194.scope”, “replace”, [(“PIDs”, <[uint32 53194]>)], @a(sa(sv)) )

Why does cursor need to start a system-d service?

thank you

3

hi @bartmr and thank you for your post.

Based on the error, this appears to be Chromium/Electron infrastructure behavior (Cursor is built on VS Code/Electron) where it attempts to register the process with systemd’s user session manager for process lifecycle management.

The call to StartTransientUnit with scope name “app-org.chromium.Chromium-*.scope” is a standard Linux desktop pattern where applications register with systemd to be properly tracked in the systemd process hierarchy. This is generally benign and optional - the error indicates your AppArmor policy is blocking it, but Cursor should continue functioning normally without it.

1 Like
4

thank you. yes it does work even with this system-d request blocked. I’ll keep it that way since I use the AppArmor sandbox to protect me from malicious extensions or supply chain attacks.