Closed ryzhyk closed 1 year ago
@ryzhyk frankly, I don't think the daemonization adds much value. I'd drop it. If we want to run it in the background, we can just use nohup <command>
.
@lalithsuresh , not a fan myself, especially because it is indeed not very well maintained. But I'm not too worried because we don't use it in "real" deployment modes. For local dev use it's kind of convenient.
I thought that @blp implemented a very rich crate for this purpose.
@lalithsuresh , not a fan myself, especially because it is indeed not very well maintained. But I'm not too worried because we don't use it in "real" deployment modes. For local dev use it's kind of convenient.
Why not just use nohup
during local dev in places where we use --unix-daemon today? It'll be just as convenient and has the benefit that you get the job ID right away if you want to shutdown the process later.
daemonize
uses pid file to prevent multiple instancesdaemonize
we can fail early before disconnecting from terminalnohup
, which I'd rather spend on other stuff :)what's the harm of keeping daemonize
around for now?
Merging #394 (8f85608) into main (dbe4663) will increase coverage by
1.21%
. The diff coverage is70.48%
.
We have two RUSTSEC alerts related to daemonize:
daemonize
usesboxfnonce
crate, which is obsolete https://github.com/vmware/database-stream-processor/issues/328daemonize
itself is unmaintained. https://github.com/vmware/database-stream-processor/issues/304We bump
daemonize
to a recent 0.5 release, which resolves (1), and I guess the fact that there is a recent release indicates that it's no longer unmaintained.