How to update electrs?
I'm having problems with Electrum 4.0.5. how can I update the electrs server to version 0.8.6? I saw in the recent issues that this new update solves the problem of connectivity with Electrum.
However I didn't find any upgrade manual in the repository guide, and the ones I found on google didn't work for me.
Can someone help me?
Whenever I try to search for the new version, I get this feedback:
HEAD is now in version 5bb6f09 Bump
When executing the cargo command, I get an error... (I followed the stadicus guide - https://stadicus.github.io/RaspiBolt/raspibolt_50_electrs.html)
link da imagem contendo o erro:
translate: https://imgur.com/GODSFQ2
bash: /usr/local/bin/cargo: unable to execute binary file: Error in exec format
Nothing fancy, just replace the binary and restart.
You're reading a guide for Raspberry Pi but not running on Raspberry Pi, so obvioudly the instructions don't work. The official electrs documentation has very detailed instructions on how to build electrs.
If you use Debian (or derived distro), then just apt install cargo works. However I wonder how did you even compile electrs without Rust in the first place?
Nothing fancy, just replace the binary and restart.
You're reading a guide for Raspberry Pi but not running on Raspberry Pi, so obvioudly the instructions don't work. The official
electrsdocumentation has very detailed instructions on how to buildelectrs.If you use Debian (or derived distro), then just
apt install cargoworks. However I wonder how did you even compileelectrswithout Rust in the first place?
When trying to install a new version of rust, the terminal returns to me that a new version is already installed, when giving the command: 'apt install cargo' it does not let me install.
I'm sorry if that sounds too basic, but I'm not really able to understand the best way to update.
My linux is Ubuntu 18.04
That should be fine, Ubuntu 18.04 has sufficient Rust version for compiling electrs. Try to build it with cargo build --release and if no error pops out, you'll find the binary in ./target/release/electrs
You might be interested in my project which intends to solve various things like how to configure these apps, how to upgrade... Beware though that you would have to somehow migrate your existing setup to take full advantage of it.
Your project is very interesting, I will keep an eye on it, I found it very promising, hopefully it will revenge and mature...
Anyway, I tried to do it now and I get the same mistakes, honestly I don't know what to do, I've tried everything.
How about making a clearer tutorial on updating the guide?
This is my process. I had to take note because i forget what I did the previous update every single time... LOL
I have Rustup installed. Make sure you follow these instructions first: https://github.com/romanz/electrs/blob/master/doc/usage.md#build-dependencies
I hope it works for you too.
UPDATE
Backup source:
cd ~
mv electrs electrs.bak
Clone repository
git clone https://github.com/romanz/electrs
cd electrs
Copy previous Configuration
cp ~/electrs.bak/config_spec.toml ~/electrs/config_spec.toml
Build
cargo build --locked --release
sudo systemctl restart electrs.service
When trying to install a new version of rust, the terminal returns to me that a new version is already installed, when giving the command: 'apt install cargo' it does not let me install.
Remove the old version of Rust first and then install rustup:
sudo apt remove rustc
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
@jonjonez what exactly happens if you run cargo build --locked --release?
The cleaner tutorial is literally start installing the whole thing again. But since there's so many ways to install it, it becomes messy if people forget how they installed it the first time.
@BTCBellyButton installing Cargo using apt is safer and cleaner. Piping stuff to sh is dangerous. rustup is only good if you're a programmer or if you have old OS and a program that requires new Rust. electrs builds with Rust 1.41.1 just fine and this version is present even in the most conservative distribution ever: Debian stable.
Also, your instructions have several big mistakes.
mv and then git clone is not very efficient, you could have just git pull - faster, easier, cleanergit checkout v0.8.6 (git clone -b v0.8.6 if you insist on cloning)config_spec.toml is NOT configuration!!! it's configuration specification and modifying it will at best make electrs uncompilable, at worst change its behavior in a very confusing way. All possible places where configuration can be are documented in the docs./usr/local/bin) before restarting the service which means that either your systemd configuration is sketchy and points into ~/electrs/target/release/eletrs or you just restarted the old electrs without any effectAnyway, I'm going to write the proper upgrade guide.
Done in https://github.com/romanz/electrs/pull/345/files
Please try to do it as instructed and report if you have any issues.
@jonjonez I would appreciate if you explained what prevents you from using my repository now, so that I can meaningfully improve it.
@Kixunil Thanks for your suggestions.
As I mentioned those were only my notes and how I could be able to make it work with my limited knowledge since I experimented issues similar to @jonjonez ones. No pretense to be a proper guide! :)
The only reason why I messed with config_spec.toml is that I'm using an external drive and auth cookie for BTC and wanted electrs db to be on that drive. I tried to follow the instructions in the "Electrs configuration" paragraph but without success. An example of a proper config.toml would really help in avoiding mistakes by users.
An upgrade guide is very appreciated! I'll try it out with the next release.
You didn't copy the resulting binary elsewhere (usually /usr/local/bin) before restarting the service which means that either your systemd configuration is sketchy and points into ~/electrs/target/release/eletrs or you just restarted the old electrs without any effect
My electrs.service:
[Unit]
Description=Electrs
After=bitcoind.service
[Service]
WorkingDirectory=/home/go/electrs
ExecStart=/home/go/electrs/target/release/electrs --db-dir /media/go/extDisk/BitcoinData/electrsdb --electrum-rpc-addr="0.0.0.0:50001"
User=go
Group=go
Type=simple
KillMode=process
TimeoutSec=60
Restart=always
RestartSec=60
[Install]
WantedBy=multi-user.target
OK, I've updated the PR to also provide an example and decrease ambiguity.
I tried to follow the instructions in the "Electrs configuration" paragraph but without success
Would be nice if you described it in more details so that we know which part of the docs is confusing.
Your electrs.service looks OK. (Note: if you've got the naming from Go language, then electrs is not written in Go ;))
if you've got the naming from Go language, then electrs is not written in Go ;)
LOL No. Those are the initials of my name. 馃槃
It's been long ago so I don't exactly remember what didn't work for me.
The very first installation was through a Ministry of Nodes tutorial: here.
Only difference was the external disk...and for that I had to venture in trial and error territory.
Reading again this part maybe should be better explained but I guess just with an example config file everything may appear more obvious to newcomers:
For each command line argument an environment variable of the same name with ELECTRS_ prefix, upper case letters and underscores instead of hypens exists (e.g. you can use ELECTRS_ELECTRUM_RPC_ADDR instead of --electrum-rpc-addr). Similarly, for each such argument an option in config file exists with underscores instead of hypens (e.g. electrum_rpc_addr). In addition, config files support cookie option to specify cookie - this is not available using command line or environment variables for security reasons (other applications could read it otherwise). Note that this is different from using cookie_path, which points to a file containing the cookie instead of being the cookie itself.
@jonjonez what exactly happens if you run cargo build --locked --release?
@Kixunil Returns that it is impossible to execute the binary, as follows:
I tried to follow the guide below, but when executing both commands: cargo build --locked --release, sudo `cp target / release / electrs / usr / local / bin, cargo install --locked --path. -f
It gives the same errors:
bash: /usr/local/bin/cargo: unable to execute the binary file: Error in exec format
Done in https://github.com/romanz/electrs/pull/345/files
Please try to do it as instructed and report if you have any issues.
When executing the command: sudo `cp target/release/electrs /usr/local/bin
Nothing happens
My electrs source was installed at: /home/myuser/rust/electrs as per the guide I followed when installing electrs for the first time: https://stadicus.github.io/RaspiBolt/raspibolt_50_electrs.html#electrs-upgrade
OK.
I just cleaned up a bit of the mess on my installation.
config.toml example file and I added the daemon_dir line:...
daemon_dir = "/media/go/extDisk/BitcoinData/"
# File where bitcoind stores the cookie, usually file .cookie in its datadir
cookie_file = "/media/go/extDisk/BitcoinData/.cookie"
# Prefer cookie file unless you have btc-rpc-proxy or a good reason to use username:password
# cookie and cookie_file can NOT be specified at the same tie.
# cookie = "username:password"
# The listening address of bitcoind, port is usually 8332
daemon_rpc_addr = "127.0.0.1:8332"
# Directory where the index should be stored. It should have at least 70GB of free space.
db_dir = "/media/go/extDisk/BitcoinData/electrsdb"
....
ExecStart entry in electrs.service[Service]
WorkingDirectory=/home/go/electrs
#ExecStart=/home/go/electrs/target/release/electrs --db-dir /media/go/extDisk/BitcoinData/electrsdb --electrum-rpc-addr="0.0.0.0:50001"
ExecStart=/home/go/electrs/target/release/electrs --conf /home/go/.electrs/config.toml
config_spec.tomlFinally
sudo systemctl daemon-reload
sudo systemctl restart electrs
and it seems to work perfectly!
@jonjonez the previous tutorial messed up your Rust installation somehow, I'm not sure how. Check if ~/.cargo/bin/cargo and ~/.cargo/bin/rustc exist. If yes: mv ~/.cargo ~/.cargo-backup and try again. You can remove ~/.cargo-backup entirely if you didn't put anything there.
If they don't exist please run which cargo and reply with the result.
@BTCBellyButton yeah, that section is not great but I'm not sure how to reword it better. Great that you figured it out!
Hi @Kixunil , I tried to make the section about configuration a little more readable.
Please see if it makes sense.
The config files (an example here) are (from highest priority to lowest): ./electrs.toml, ~/.electrs/config.toml, /etc/electrs/config.toml.
The options in highest-priority config files override options set in lowest-priority config files.
Environment variables override options in config files and finally command line arguments override everything else.
There are two special arguments --conf which reads the specified config file and --conf-dir, which read all the config files in the specified directory.
The options in those files override everything that was set previously, including arguments that were passed before these two special arguments.
In general, later arguments override previous ones. It is a good practice to use these special arguments at the beginning of the command line in order to avoid confusion.
Naming convention
For each command line argument an environment variable of the same name with ELECTRS_ prefix, upper case letters and underscores instead of hyphens exists (e.g. you can use ELECTRS_ELECTRUM_RPC_ADDR instead of --electrum-rpc-addr).
Similarly, for each such argument an option in config file exists with underscores instead of hypens (e.g. electrum_rpc_addr).
Authentication
In addition, config files support a cookie option to specify cookie - this is not available using command line or environment variables for security reasons (other applications could read it otherwise). Note that this is different from using cookie_path, which points to a file containing the cookie instead of being the cookie itself.
If you are using -rpcuser=USER and -rpcpassword=PASSWORD of bitcoind for authentication, please use cookie="USER:PASSWORD" option in one of the config files. Otherwise, ~/.bitcoin/.cookie will be used as the default cookie file, allowing this server to use bitcoind JSONRPC interface.
Finally, you need to use a number in config file if you want to increase verbosity (e.g. verbose = 3 is equivalent to -vvv) and true value in case of flags (e.g. timestamp = true)
Looks much cleaner, I'm not sure if linking the config that way is the best way of conveying that it's an example.
Not sure if I'd highlight "option" and "Note" that way, looks a bit off to me.
My creativity is low at this moment so I don't have good ideas to tweak it.
@Kixunil I changed just a couple of things to reflect your points.
I remember when reading about the cookie that I was a bit confused.
It's not clear to me what cookie_path is supposed to be.
Maybe it should read:
"... _which points to a DIRECTORY containing the cookie instead of being the cookie itself._"?
No, it's not directory, it's a file. I now realize where your confusion may come from:
.cookie which makes it invisible by default on Unix-like OSescookie is called as such from the old days when custom cookie path was not implemented, today it should be used mainly as username:password since cookie_path is a much better option for setting actual cookie. - I'm going to open a separate issue about renaming it.I'm not sure electrs should be a place for in-depth explanation of the former two things but a short explanation should be fine. It should be understandable from the following paragraph but maybe people stop reading when they are confused?
I'm thinking about separating it to two sections: Cookie authentication - explain that bitcoind creates a (usually hidden) cookie file on each start and every application that reads it can access bitcoind and usually user should set this path in electrs config to access bitcoind. The other section would be called Username/password authentication and explain that explicit username:password can be given in the cookie option in config file.
What do you think?
No, no I know what .cookie is.
The confusion is from using similar options to point to the same file:
I used the 3rd one in electrs config file, since I am not using the bitcoind default directory, and it works.
Separating the two ways in a more explicit way should help a lot.
But then what's the difference between cookie_path and cookie_file?
The difference is cookie_file actually exists while cookie_path doesn't and is mistakenly used in docs. I will create a PR with your suggestions and fix of this mistake. Do you have any more suggestions?
I also suggested to rename cookie, see: https://github.com/romanz/electrs/issues/349
Well that was the origin of most of my troubles with electrs configuration. LOL
Glad we found out!!
The PR #349 makes a lot of sense!
Beside rewriting the cookie section better, I don't see much else.
Most helpful comment
@jonjonez what exactly happens if you run
cargo build --locked --release?The cleaner tutorial is literally start installing the whole thing again. But since there's so many ways to install it, it becomes messy if people forget how they installed it the first time.
@BTCBellyButton installing Cargo using apt is safer and cleaner. Piping stuff to
shis dangerous.rustupis only good if you're a programmer or if you have old OS and a program that requires new Rust.electrsbuilds with Rust 1.41.1 just fine and this version is present even in the most conservative distribution ever: Debian stable.Also, your instructions have several big mistakes.
mvand thengit cloneis not very efficient, you could have justgit pull- faster, easier, cleanergit checkout v0.8.6(git clone -b v0.8.6if you insist on cloning)config_spec.tomlis NOT configuration!!! it's configuration specification and modifying it will at best make electrs uncompilable, at worst change its behavior in a very confusing way. All possible places where configuration can be are documented in the docs./usr/local/bin) before restarting the service which means that either yoursystemdconfiguration is sketchy and points into~/electrs/target/release/eletrsor you just restarted the oldelectrswithout any effectAnyway, I'm going to write the proper upgrade guide.