Wrapper Process for Erigon

[praetoriansentry]

Description

In several of our manual test procedures, we need a way to stop Erigon, but keep the container alive so that we can do an unwind or some other operations within the container. In an ideal world, I think the data on disk would ideally be in a volume so that we could just kill the container. We don't have that setup right now.

The PR creates a proc-runner.sh Bourne Shell (not bash) script that starts a child process. If that child process dies, this process will also exit properly. However, if we send a SIGTRAP signal to the to the parent process, the child will be gracefully terminated and then a new child process will be started that runs tail -f /dev/null. The idea is to have something that runs forever and keeps the container up and running.

In addition to the process manager, there are a few other changes:

• We've tried to standardize on rpc and ws-rpc for the port names for RPC and websockets (fyi @vcastellm )
• Updated to the latest version of the bridge service (fyi (@ARR552 )
• Whitespace cleanup on the config file
• Adding the sanity check URL with a temporary configuration that points directly to the sequencer URL

[cffls]

LGTM

[vcastellm]

nice!

[vcastellm]

What it will take to go to the ideal world and maintain the data in a volume?

[praetoriansentry]

What it will take to go to the ideal world and maintain the data in a volume?

Good question. So it's already technically possible. The data directory, or whatever directory we want access to, would need to be running within a Kurtosis Directory. If you do that, your data is in a docker volume.

The challenge is finding where that volume is ultimately mounted on your host OS. It's pretty easy on linux, but I'm not sure how easy / hard it would be in the mac Docker Desktop setup. In my case..

1. Get a container name that you're interested in messing with
2. Check its mount points docker inspect cdk-erigon-sequencer-001--8771f8c91967470ea69f44756a8a9ef5 | jq '.[].Mounts'
3. Start hacking away.

I didn't opt for this solution because it's a little tricky to do and it also doesn't help in some of the other testing scenarios that I do. Docker volumes would work will if the data directory is in a volume and we want to run some commands against the data from the host OS... But that requires that whatever tools that you need are actually in the host OS. A lot of the tools are actually in the container, so it's actually more convenient to run the command from within the container. The other benefit of this setup is we can do weird stuff like updating the version of the binary in the container without changing the image!! E.g. in order to test a new feature before a container is created, I can build a new version of the binary, stop the process, and docker cp the new binary in place. It's complicated, but helpful.