Starting replication process with Procfile

[dhmacs]

The README of the project says that the replication process can be started with a procfile:

# Procfile
rails: bundle exec rails server --port $PORT
litestream: bin/rails litestream:replicate

It seems though that if bin/rails litestream:replicate executes asynchronously, foreman (or whatever process monitor) would exit, stopping the other processes as well, correct? I'm asking this because this is what's happening when I try this setup (when I run the puma plugin it works).

This seems to affect other commands like restore as well, which makes it hard to implement sequential logic (e.g. restoring the db before running bin/rails db:prepare — useful when migrating to a new server for distaster recovery)

[olinelson]

Interesting. I can successfully run litestream with the puma plugin in Rails 8 but running as a separate process just exits. An excerpt from my Kamal config:

servers:
  web:
    - 170.64.240.47
  worker:
    hosts:
        - 170.64.240.47
    cmd: bin/jobs
  litestream:
    hosts:
      - 170.64.240.47
    cmd: bin/rails litestream:replicate

[fractaledmind]

Any logs? I'd love to fix this, but would need a bit more info around what is going on

[ttilberg]

I believe this is a side-effect of an issue I was going to bring up today related to process backgrounding. Since I think it's related, I'll leverage this existing issue.

I tried Litestream for the first time this past week, and was surprised that the default rake task for litestream:replicate backgrounded the process and returned control to my shell immediately. It continued to write to stdout (or stderr perhaps) but there was no pid available. The only way to stop the process was to search for the pid and kill it separately.

I believe this behavior would cause the same as OP's note.

While researching this, I noticed https://github.com/fractaledmind/litestream-ruby/commit/c00231630107b39bd3fa1b610571f67ea7be6959 which sets default command async to false, with the rake tasks overriding as true. I believe this is what's implied by the async option in the command.

I found this same behavior with the minio gem while working on an example to provide here.

However, editing the gem to use async: false in the rakefile prevents any stdout/stderr at all. It does keep the proc foregrounded though for easy exit.

Without knowing the intentions of the ecosystem as a whole, I feel out of place recommending specific changes, but I found the behavior surprising and would like to either correct it or update the readme with more information.

https://asciinema.org/a/HekxdZNqOytndDPWLfYjvp9e6