Truffle migration stuck

Question

I am trying to migrate contract on a block chain network created using azure ethereum consortium blockchain, But when I am running the command Truffle migrate it stuck at

 PS D:\sl\BCSLAC\bcdemo\sol> truffle migrate --network test
 Using network 'test'.

 Running migration: 1_initial_migration.js
 Deploying Migrations...

This message persists for long time and nothing happens after this, Can some one have idea what is the problem,

And the interesting thing is I have one more block chain network setup on azure(which I am using previously), If I try to deploy it on that network It works fine but not on the new one

I have searched for this issue and found one solution here which says delete DAG file, As I am using Windows 7, the dag file location must be

(HOME)/Appdata/Local/Ethash/full......

but I cant see any folder named Ethash in my AppData/Local folder

Answer 1

One thing that can cause this behaviour with Parity (not sure if that's what the Azure service is running or not) is that if the account it wants to deploy with is locked, as it is by default, it expects you to take some other step to approve the transaction.

Parity tries to do this by running a web UI on some other port, showing each transaction request on a web screen, and waiting for you to click it. Unfortunately truffle doesn't know about this, and doesn't tell you anything about the existence of this web screen or the request that's displayed on it.

To stop it doing this, unlock the sending account when you start the parity node. For example, when running with the example accounts used in the Parity PoA tutorial, put the passwords in a file called user.pwds and run parity with:

parity --config node0.toml --unlock 0x004ec07d2329997267ec62b4166639513386f32e,0x00bd138abd70e2f00903268f3db08f2d25677c9e --password user.pwds

The passwords file contains the passwords to the accounts, one per line, eg:

node0
user

Answer 2

I faced the same issue. I checked everything from active miners to account being locked. At the end, restarting the transaction node from Azure portal did the trick for me.

Answer 3

The problems I face was a combination of many:

1. The account should be unlocked before transaction could be mined.
2. The miners should be running if the transaction should be mined.
3. The sender should be sending sufficient gas.
4. Signers were enabled but I was unable to sign transactions since I could not access them on UI(I was testing code on server). To disable secure signers, I used --no-ui while running parity.

To overcome these problems, I used a private chain with following configuration:

The chain specifications were borrowed from private-chain and stored in file named demo-spec.json:

{
    "name": "DevelopmentChain",
    "engine": {
        "instantSeal": { "params": {} }
    },
    "params": {
        "accountStartNonce": "0x0",
        "maximumExtraDataSize": "0x20",
        "minGasLimit": "0x1388",
        "networkID" : "0x11"
    },
    "genesis": {
        "seal": {
            "generic": "0x0"
        },
        "difficulty": "0x20000",
        "author": "0x0000000000000000000000000000000000000000",
        "timestamp": "0x00",
        "parentHash": "0x0000000000000000000000000000000000000000000000000000000000000000",
        "extraData": "0x",
        "gasLimit": "0x5B8D80"
    },
    "accounts": {
        "0000000000000000000000000000000000000001": { "balance": "1", "builtin": { "name": "ecrecover", "pricing": { "linear": { "base": 3000, "word": 0 } } } },
        "0000000000000000000000000000000000000002": { "balance": "1", "builtin": { "name": "sha256", "pricing": { "linear": { "base": 60, "word": 12 } } } },
        "0000000000000000000000000000000000000003": { "balance": "1", "builtin": { "name": "ripemd160", "pricing": { "linear": { "base": 600, "word": 120 } } } },
        "0000000000000000000000000000000000000004": { "balance": "1", "builtin": { "name": "identity", "pricing": { "linear": { "base": 15, "word": 3 } } } },
        "0x00a329c0648769a73afac7f9381e08fb43dbea72": { "balance": "1606938044258990275541962092341162602522202993782792835301376" },
                "0x004ec07d2329997267ec62b4166639513386f32e": {"balance": "9999999999999999999999999999999999999999999999999999999999999999999999"},
                "0x00bd138abd70e2f00903268f3db08f2d25677c9e": {"balance":"999999999999999999999999999999999999999999999999999999999999999999999999"}
    }
}

The next step was to create node0.toml file:

[parity]
chain = "demo-spec.json"
base_path = "./tmp/parity0"
[network]
port = 30300
[rpc]
port = 8540
apis = ["web3", "eth", "net", "personal", "parity", "parity_set", "traces", "rpc", "parity_accounts"]
[websockets]
port = 8450
[account]
password = ["node.pwds"]
[mining]
reseal_min_period = 0
min_gas_price = 0

Don't start the node yet, we have not saved password yet. Save the following content in node.pwds file:

node0
user

Now start the node using

parity --config node0.toml

The accounts exist in the chain, but they are not saved in the node that we are running. Before we could get our accounts working, we need to create them on our node. I did it using RPC:

curl --data '{"jsonrpc":"2.0","method":"parity_newAccountFromPhrase","params":["node0", "node0"],"id":0}' -H "Content-Type: application/json" -X POST localhost:8540

curl --data '{"jsonrpc":"2.0","method":"parity_newAccountFromPhrase","params":["user", "user"],"id":0}' -H "Content-Type: application/json" -X POST localhost:8540

Now everything is ready and we can start the parity node by unlocking the account:

parity --config node0.toml --no-ui --unlock 0x004ec07d2329997267ec62b4166639513386f32e,0x00bd138abd70e2f00903268f3db08f2d25677c9e --password node.pwds

Note:

1. UI is disabled. I disabled the secure signer by using --no-ui. UI can be enabled by modifying node0.toml and changing the command to run parity by excluding --no-ui.
2. Above procedure is used to test truffle code on server with rpc on port 8540.