storm-wg/storm-stored

Storage daemon for Storm and other LNP/BP nodes - an embeddble microservice frontend for different storage backends

storm-stored's Issues

Docker: stored doesn't seem to accept connection with IPv4

I've been doing some tests with my Docker stack, and I've noticed that other daemons (rgbd and stormd) can't connect to stored RPC API using IPv4 (Docker hostnames). Full compose file.

  rgb-node:
    image: louneskmt/rgb-node:v0.8.0-rc.1
    init: true
    command:
      - -vvv
      - --chain=testnet
      - --storm=storm-node:64964
      - --store=storm-stored:60960
      - --data-dir=/var/lib/rgbd
    volumes:
      - ./data/rgb-node:/var/lib/rgbd
    expose:
      - 63963 # RGB RPC

  storm-stored:
    image: louneskmt/storm-stored:v0.8.0
    init: true
    command:
      - -vvv
      - --data-dir=/var/lib/stored
      - --rpc=0.0.0.0:90960
    volumes:
      - ./data/storm-stored:/var/lib/stored
    expose:
      - 60960

stored starts normally and opens the RPC API socket to 0.0.0.0:60960:

instance1-storm-stored-1  | stored: storage microservice
instance1-storm-stored-1  | [2022-07-17T10:33:29Z DEBUG stored] CTL RPC socket 0.0.0.0:60960
instance1-storm-stored-1  | [2022-07-17T10:33:29Z DEBUG stored] Starting runtime ...
instance1-storm-stored-1  | [2022-07-17T10:33:29Z DEBUG stored::service] Opening RPC API socket 0.0.0.0:60960
instance1-storm-stored-1  | [2022-07-17T10:33:29Z DEBUG stored::service] Opening database at /var/lib/stored/sled.db
instance1-storm-stored-1  | [2022-07-17T10:33:29Z DEBUG sled::pagecache::iterator] ordering before clearing tears: {0: 0}, max_header_stable_lsn: 0
instance1-storm-stored-1  | [2022-07-17T10:33:29Z DEBUG sled::pagecache::iterator] in clean_tail_tears, found missing item in tail: None and we'll scan segments {0: 0} above lowest lsn 0
instance1-storm-stored-1  | [2022-07-17T10:33:29Z DEBUG sled::pagecache::iterator] filtering out segments after detected tear at (lsn, lid) 2786
instance1-storm-stored-1  | [2022-07-17T10:33:29Z DEBUG sled::pagecache::iterator] hit max_lsn 2786 in iterator, stopping
instance1-storm-stored-1  | [2022-07-17T10:33:29Z DEBUG sled::pagecache::snapshot] zeroing the end of the recovered segment at lsn 0 between lids 2787 and 524287
instance1-storm-stored-1  | [2022-07-17T10:33:29Z DEBUG sled::pagecache::blob_io] gc_blobs removing any blob with an lsn above 2787
instance1-storm-stored-1  | [2022-07-17T10:33:29Z DEBUG sled::pagecache::segment] SA starting with tip 524288 stable -1 free {}
instance1-storm-stored-1  | [2022-07-17T10:33:29Z DEBUG sled::pagecache::iobuf] starting log at recovered active offset 2787, recovered lsn 2787
instance1-storm-stored-1  | [2022-07-17T10:33:29Z DEBUG sled::pagecache::iobuf] starting IoBufs with next_lsn: 2787 next_lid: 2787
instance1-storm-stored-1  | [2022-07-17T10:33:29Z DEBUG sled::pagecache] load_snapshot loading pages from 0..38
instance1-storm-stored-1  | [2022-07-17T10:33:29Z INFO  stored::service] Stored runtime started successfully

rgbd tries to initialize the runtime connecting to the store service, but never succeeds:

instance1-rgb-node-1      | rgbd: RGB stash microservice
instance1-rgb-node-1      | [2022-07-17T10:33:29Z DEBUG rgbd] CTL socket /var/lib/rgbd/ctl
instance1-rgb-node-1      | [2022-07-17T10:33:29Z DEBUG rgbd] RPC socket 0.0.0.0:63963
instance1-rgb-node-1      | [2022-07-17T10:33:29Z DEBUG rgbd] STORE socket storm-stored:60960
instance1-rgb-node-1      | [2022-07-17T10:33:29Z DEBUG rgbd] STORM socket storm-node:64964
instance1-rgb-node-1      | [2022-07-17T10:33:29Z DEBUG rgbd] Starting runtime ...
instance1-rgb-node-1      | [2022-07-17T10:33:29Z DEBUG rgb_node::rgbd::service] Connecting to store service at storm-stored:60960
instance1-rgb-node-1      | [2022-07-17T10:33:29Z DEBUG store_rpc::client] Initializing runtime

If I change the configuration to use a socket file, it suddenly works as expected.

  rgb-node:
    image: louneskmt/rgb-node:v0.8.0-rc.1
    init: true
    command:
      - -vvv
      - --chain=testnet
      - --storm=storm-node:64964
      - --store=/var/lib/stored/store
      - --data-dir=/var/lib/rgbd
    volumes:
      - ./data/rgb-node:/var/lib/rgbd
      - ./data/storm-stored:/var/lib/stored
    expose:
      - 63963 # RGB RPC

  storm-stored:
    image: louneskmt/storm-stored:v0.8.0
    init: true
    command:
      - -vvv
      - --data-dir=/var/lib/stored
      - --rpc=/var/lib/stored/store
    volumes:
      - ./data/storm-stored:/var/lib/stored

Can this be due to the daemons not supporting hostnames? Or is it for sure an issue with Docker (or my Docker stack)?

store_daemon crate missing documentation

currently store_daemon is missing the documentation link on crates.io

the documentation build fails on docs.rs, which also means packages depending on store_daemon experience the same failure and are left without documentation

here's an excerpt from the build log:

[INFO] [stderr] error: failed to run custom build command for `store_daemon v0.8.0 (/opt/rustwide/workdir)`
[INFO] [stderr] 
[INFO] [stderr] Caused by:
[INFO] [stderr]   process didn't exit successfully: `/opt/rustwide/target/debug/build/store_daemon-e23b63f1c34f0995/build-script-build` (exit status: 1)
[INFO] [stderr]   --- stderr
[INFO] [stderr]   Error: I/O error: Read-only file system (os error 30)

I was able to reproduce it by running cargo rustdoc in docker with the project mounted read-only (and target/ mounted read-write) and confirm the issue seems to be in build.rs, as it tries to write to the hard-coded ./shell directory

according to the docs.rs documentation this should be dealt with by using the OUT_DIR environment variable to source the writable path for the build script

in the case of store_daemon, build.rs (and cli/build.rs using ../shell) could be updated to something like:

use std::env;

...
    let outdir = match env::var("OUT_DIR") {
        Ok(d) => d,
        Err(_) => "./shell".to_string(),
    };

but I'm not sure about other implications of this change

@dr-orlovsky could you please take a look at it?

Sled never exits

When running an embedded inproc stored node, being used in a test pointed at /tmp, and with RUST_LOG set to trace, I get the following output:

 ERROR my_project                                    > Error ...
 TRACE mio::poll                                     > deregistering event source from poller
 TRACE want                                          > signal: Closed
 TRACE mio::poll                                     > deregistering event source from poller
 TRACE want                                          > signal: Closed
 TRACE mio::poll                                     > deregistering event source from poller
 TRACE want                                          > signal: Closed
 TRACE mio::poll                                     > deregistering event source from poller
 TRACE want                                          > signal: Closed
 TRACE mio::poll                                     > deregistering event source from poller
 TRACE sled::pagecache::iobuf                        > skipping roll_iobuf due to empty segment
 TRACE sled::pagecache::iobuf                        > bumping atomic header lsn to -1
 TRACE sled::pagecache::iobuf                        > skipping roll_iobuf due to empty segment
 TRACE sled::pagecache::iobuf                        > skipping roll_iobuf due to empty segment
 TRACE sled::pagecache::iobuf                        > skipping roll_iobuf due to empty segment
 TRACE sled::pagecache::iobuf                        > skipping roll_iobuf due to empty segment
 TRACE sled::pagecache::iobuf                        > skipping roll_iobuf due to empty segment
 TRACE sled::pagecache::iobuf                        > skipping roll_iobuf due to empty segment
^C

This also causes failing tests in CI to churn endlessly.

Using:
sled: 0.34.7
rustc: 1.63.0
OS: arch (btw)

could not acquire lock DB and panicked.

Hello.

I'm developing my RGB-Wallet using https://github.com/rgb-tools/rgb-lib.
It uses storm-stored.
And I got panick in stored related code.

https://github.com/RGB-Tools/rgb-lib/blob/1028e9aff8e72fe79987a85bda9b2abfa5717883/src/wallet/mod.rs#L1693

The log from the test code is:

thread '<unnamed>' panicked at 'running stored runtime: AppLevel(Database(Io(Custom { kind: Other, error: "could not acquire lock on \"/tmp/shiro-wallet/60ec7707/sled.db/db\": Os { code: 11, kind: WouldBlock, message: \"Resource temporarily unavailable\" }" })))', /home/monaka/.cargo/git/checkouts/rgb-lib-b21a551c0f942d1d/d1de142/src/wallet/mod.rs:1693:42

I found /tmp/shiro-wallet/60ec7707/sled.db/db in my test machine.
I checked rm -fr /tmp/shiro-wallet/ && mkdir -p /tmp/shiro-wallet and it doesn't fix this issue.

I raised the similar issue RGB-Tools/rgb-lib#15 because I can't determine which component is the root cause.

Could you give me any hints to shoot my trouble ?