fix: fix docker start command

[jcstein]

Overview

Resolves #1228
running with persistent storage logs

Checklist

• New and updated code has appropriate documentation
• New and updated code has new and/or updated testing
• Required CI checks are passing
• Visual proof for any user facing features like CLI or documentation updates
• Linked issues closed with keywords

[github-actions]

PR Preview Action v1.4.4
🚀 Deployed preview to https://celestiaorg.github.io/docs/pr-preview/pr-1237/
on branch gh-pages at 2023-11-10 16:06 UTC

[keyneom]

This should be added here:

-e CELESTIA_HOME=/celestia

or a section above should be added exporting a variable that can be used here like the others.

Or the other option would be to modify the default docker environment variable to use the /celestia path instead of /home/celestia.

Or you may want to switch the other commands back to using /home/celestia for the mounted volume instead of /celestia to maintain persistence.

[jcstein]

i tested the full command when i edited this doc and it worked as expected. -v $HOME/my-node-store:/celestia \ does the trick

[jcstein]

what OS are you on? i think that may be the issue. this doc works for mac and linux.

[keyneom]

I've executed it both within windows and Ubuntu WSL. Are you sure it is actually persisting in your testing? The command executes successfully as written for me as well, it just doesn't actually persist anything. So after running it you can check in the $HOME/my-node-store folder on your host machine and find no files or directories were created (of course you should wipe the directory first to ensure it is empty to begin with and isn't using the data from previous runs).

So while I think all of the commands in the docs will not currently throw any errors, I do believe they are not correct as currently written as they will not achieve the intended goal of a persistent node. Perhaps I messed up somehow though.

[jcstein]

got it, i’ll test to verify!

[keyneom]

The original comment in this thread was to fix the persistence issue I had encountered.

[keyneom]

I'd make a note that trying to run the docker images in windows is likely to run into issues due to the way NTFS handles permissions and that referencing a volume that supports linux permissions (such as within WSL2) is a good way for Windows users to be able to run a node with persistent storage.

[jcstein]

please feel free to make a PR to add the instructions that work for you on Windows!

[jcstein]

for the scope of this PR, i'd just like to fix the docker commands that do work. hopefully you understand 🙏

[keyneom]

For sure that's totally reasonable. I do think--like I mentioned above--that the current commands do not achieve the intended objective of persisting a node although they may not throw any errors but perhaps you are referencing a different version of the docker container or something like that which works.

[keyneom]

@jcstein I created this PR #1249 feel free to modify/improve wording as much as you feel is appropriate.

[keyneom]

The additional parameter I recommend adding to the docker commands should fix this so that it does persist correctly. That, or the other options I mentioned in the other comment thread above should work as well.

[jcstein]

Understood! What is the full start command then? As I understand the -v $HOME/my-node-store:/home/celestia flag would still be used?

[jcstein]

docker run -e NODE_TYPE=$NODE_TYPE -e P2P_NETWORK=$NETWORK -e CELESTIA_HOME=/celestia -v $HOME/my-node-store:/celestia ghcr.io/celestiaorg/celestia-node:v0.12.0 celestia $NODE_TYPE init --p2p.network $NETWORK
Initializing Celestia Node with command:
celestia light init --p2p.network celestia
2023-11-09T10:36:03.394Z	INFO	node	nodebuilder/init.go:31	Initializing Light Node Store over '/celestia/.celestia-light'
Error: mkdir /celestia/.celestia-light: operation not permitted

[jcstein]

it appears to be something related to permissions in the container itself afaiu. here are full logs

[jcstein]

after changing the path back to /home/celestia and using your -e CELESTIA_HOME=/home/celestia flag, i hit an error not being able to create the directory in the container?

[smuu]

So my findings:

• when using /home/celestia instead of /celestia, the keys and the data are persisted (the node uses this if not specified otherwise
• when using Mainnet Beta, we don't need to set P2P_NETWORK as this points by default to the celestia network
• NODE_TYPE is not needed at all, I think, as this is only used when automatically calling init when starting, but as we have persistent data and we init manually, this is not needed in this section

This should resolve the bug and make this section a little cleaner.

[jcstein]

copying this for vis @smuu

after changing the path back to /home/celestia and using your -e CELESTIA_HOME=/home/celestia flag, i hit an error not being able to create the directory in the container?

[jcstein]

i plan to use p2p network and node type so that users can set up env once in above section in order to not have to explain/set the same variables twice

[smuu]

i plan to use p2p network and node type so that users can set up env once in above section in order to not have to explain/set the same variables twice

I understand, then I propose to use $NODE_TYPE also in the init and start commands, as those are hardcoded to light at the moment.

[smuu]

copying this for vis @smuu

after changing the path back to /home/celestia and using your -e CELESTIA_HOME=/home/celestia flag, i hit an error not being able to create the directory in the container?

I can't reproduce this behavior.
When following the steps of creating the folder and changing the permissions, I can run the container with the init.

[keyneom]

copying this for vis @smuu
after changing the path back to /home/celestia and using your -e CELESTIA_HOME=/home/celestia flag, i hit an error not being able to create the directory in the container?

I can't reproduce this behavior. When following the steps of creating the folder and changing the permissions, I can run the container with the init.

That is my experience as well. As long as the permissions are set with the prior command (chown) then I don't encounter any errors and things persist correctly.

[keyneom]

So my findings:

• when using /home/celestia instead of /celestia, the keys and the data are persisted (the node uses this if not specified otherwise
• when using Mainnet Beta, we don't need to set P2P_NETWORK as this points by default to the celestia network
• NODE_TYPE is not needed at all, I think, as this is only used when automatically calling init when starting, but as we have persistent data and we init manually, this is not needed in this section

This should resolve the bug and make this section a little cleaner.

I believe the docs as written are intended to support running on test nets, etc so I'd leave the P2P_NETWORK as is. I do think it makes sense to just use /home/celestia since it is the default. I wasn't clear on the other factors that may have been driving a switch to /celestia.

[jcstein]

I think we're in good shape now!

[smuu]

lgtm

[keyneom]

Lgtm