search

doy / rbw

unofficial bitwarden cli
https://git.tozt.net/rbw
Other
611 stars 84 forks source link

Running in a systemd service #87

Open alarsyo opened 2 years ago

alarsyo commented 2 years ago

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 a simple systemd service type, instead of forking).

I've found the --no-daemonize flag but in that case it doesn't seem like rbw-agent will run the make_all function, skipping creation of the runtime directory, and thus failing to then create the socket (since the rbw/ directory doesn't exist). I could mkdir /run/user/UID/rbw before launching, but then pidfile isn't created anyway, which leads to another rbw-agent being launched anyway if I rbw 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.

alarsyo commented 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.

Witcher01 commented 2 years ago

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.

doy commented 1 year ago

i'm not sure i really understand the goal here. why is it useful to run the agent separately?

somini commented 1 year ago

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.

freswa commented 8 months ago

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.