When I run an instance with --path <path> and then send the process a SIGTERM, the data directory remains locked, which prevents it being used by a second process. For example:
$ mkdir -p foo
$ kinesalite --path foo &
Listening at http://:::4567
$ kill $!
$ ls -lah foo
total 24
drwxr-xr-x 7 baz bar 224B 30 Nov 18:04 .
drwxr-xr-x 11 baz bar 352B 30 Nov 18:04 ..
-rw-r--r-- 1 baz bar 0B 30 Nov 18:04 000003.log
-rw-r--r-- 1 baz bar 16B 30 Nov 18:04 CURRENT
-rw-r--r-- 1 baz bar 0B 30 Nov 18:04 LOCK
-rw-r--r-- 1 baz bar 57B 30 Nov 18:04 LOG
-rw-r--r-- 1 baz bar 50B 30 Nov 18:04 MANIFEST-000002
Normally, SIGTERM is expected to be handled gracefully, and shut down any in-use resources before exiting.
Rationale
Why run two instances (one after the other) with the same --path anyway? Well, I'm basically trying to pre-create a bunch of streams in a Docker entrypoint script, and I'm doing exec kinesalite "${@}" at the end of that script to avoid the PID-1 signal-handling problem. (But as Kinesalite doesn't seem to handle signals well, perhaps that's overkill anyway!)
Problem
When I run an instance with
--path <path>and then send the process a SIGTERM, the data directory remains locked, which prevents it being used by a second process. For example:Normally, SIGTERM is expected to be handled gracefully, and shut down any in-use resources before exiting.
Rationale
Why run two instances (one after the other) with the same
--pathanyway? Well, I'm basically trying to pre-create a bunch of streams in a Docker entrypoint script, and I'm doingexec kinesalite "${@}"at the end of that script to avoid the PID-1 signal-handling problem. (But as Kinesalite doesn't seem to handle signals well, perhaps that's overkill anyway!)