# Troubleshooting ## Current version of go-u2u The current supported version is go-u2u, branch `stable` for both mainnet and testnet. ## Pruning node state If your node is about to run out of space, you might think about adding more storage OR pruning the datadir on the current node. Please use the following steps to prune the datadir: ### **Manual pruning** * Stop the node\ `pkill u2u` * Open up your Terminal, then run:\ `./u2u snapshot --db.preset prune-state` Depending on the machine's speed, the state pruning procedure could take a few hours for every several hundred gigabytes of data. So, you can run while using `nohup`. ### **Automatic pruning** To enable automatic pruning, you can run a node with `--gcmode` flag, either `--gcmode full` or `--gcmode light`.\ \ Note that: * Both `--gcmode full` and `--gcmode light` will prune data that is processed after gcmode is enabled. Old data (before gcmode is enabled) is untouched. * Validator node can use `--gcmode light` but should not use `--gcmode full`. * `--gcmode full` option will prune much more EVM nodes than `--gcmode light` at expense of worse performance. ## Validator node ### **How to rerun a node if it is stopped** If your node is down (for any reason), please review the server logs to determine if there is a problem. After fixing the problem (if any), you can run the node in read mode to synchronize it with the last block. Once synchronized, you can stop the node and run it in validator mode. Note that first make sure your node is synchronized under a normal node before running it in validator node. ### **Migration to a new server** If you want to move your node to a new server, please follow these steps: * Set up a normal node on the new server and enable it to run to sync with the latest block. * Turn off the old node at least 40 minutes before running validator mode on the new server. * After the old node is down for 40 minutes, you can run in authentication mode on the new server. Note that you should not leave the old node running again because this will cause your authentication node to be double-signed and slashing of your validator node. ### **How to stop a node** Find u2u's running process by `ps`, then `kill` the process by id. Note that after your node is stopped, if you want to run it again, do not run it directly in validator mode. Instead, first make sure your node is synchronized in normal mode before running it in validator mode. ### **Offline node** If your validator node is inactive for more than 5 days, it will go offline (i.e. removed from the network). For offline nodes, you can undelegate and wait 7 days for withdrawal (bonding time). You can then transfer funds to a new wallet and create a new validator if you want. Note that if you cancel a locked stake authorization or a locked authorization before the lockup period expires, this will result in a penalty. ### **How to permanently shut down a node** To permanently disable a node, simply stop running it in validator mode for 5 days or more. It will then become offline. ### **How to unstake** Please reference at [Staking](https://docs.u2u.xyz/services/staking). ## Troubleshooting ### **Syncing error** If your node is in dirty state (it may happen occasionally), please run:\ `u2u --db.preset legacy-ldb db heal --experimental`\ \ lternatively, you may do a fresh resync as follows: * Stop the node * Remove the current (broken) datadir (the default datadir is located at \~/.u2u) * Download and build the latest version go-u2u * Run your node again in normal mode ### **Slow syncing** Check your machine specs if it meets the minimum requirements. * IOPS greater than 5000 (higher is better) * connection speed > 1 Gbps (some ppl run with 10 or 20, if they can) * cores: more than 4 cores (the number of cores is not important unless you will use it for serving API calls). * CPU: > 3GHz. You can also check the following flags, if you're using them to run your node. You can adjust to values suitable to your usage. * `maxpeers` flag: default is 50, you can adjust it depending on your machine. * `cache` flag: `--cache 15792` (A larger value can give better performance). * `gcmode`: gcmode is not enabled by default. If enabled, [gcmode](#2.2-automatic-pruning) (light or full) it will take some extra CPU and time. You can also increase the value of [`ulimit`](#increase-open-files-limit) on your machine as below. ## **Increase open files limit** You can check your current limit value on Linux with the command `ulimit -n`. The default value of 1024, which may be not enough in some cases. You can adjust the value to the recommended 500.000 open files limit by either:\ \- `ulimit -n 500000` \ \- change it in `/etc/security/limits.conf` configuration file, limit type nofile.