Open alarsyo opened 2 years ago
To elaborate, currently the rbw
CLI always starts rbw-agent and rbw-agent just doesn't daemonize if it finds a pidfile. I think rbw
should instead try to connect to the socket, and only spawn rbw-agent
if it doesn't find the socket already opened. This way a rbw-agent
launched with --no-daemonize
will be usable.
FWIW, systemd supports creation of a runtime directory when the service starts using RuntimeDirectory=
(given path will be in /run
IIRC) and pidfile creation with PIDFile=
. You'll find more info on these in the man page.
Not sure if it helps but it might be a viable workaround to implementing this in rbw
for now.
i'm not sure i really understand the goal here. why is it useful to run the agent separately?
i'm not sure i really understand the goal here. why is it useful to run the agent separately?
Speaking for myself, I don't want to manually manage another daemon, or have no visibility into state, handle multiple daemon instances, etc etc.
Running in a separate systemd service would also allow to capture STDOUT easily and write it to the users journal. At least for other user daemons it has helped me quite a lot while debugging issues.
Hi!
I'm trying to run
rbw-agent
in a systemd user service. To keep the setup simple, I'd like it to not fork when launched (to use asimple
systemd service type, instead offorking
).I've found the
--no-daemonize
flag but in that case it doesn't seem likerbw-agent
will run themake_all
function, skipping creation of the runtime directory, and thus failing to then create the socket (since therbw/
directory doesn't exist). I couldmkdir /run/user/UID/rbw
before launching, but thenpidfile
isn't created anyway, which leads to anotherrbw-agent
being launched anyway if Irbw unlock
.Using the
forking
systemd service type works, but it'd be great if there was a flag to run the agent in the foreground.