I'm trying to set up a CRON job to run maintenance actions in my contract on a regular basis. CRON will call a shell script containing cleos 'push action' commands. The problem is that 'push action' commands must be run with an account's permission, and a wallet must be unlocked to provide authentication of the specified account.

In theory I could unlock the wallet, tell keosd to set the the wallet timeout to seconds, but all of that won't help in the case of a system reboot. This technique doesn't sound very reliable or secure in any case.

Has anyone solved these problems? I'm trying to keep things simple for now and not use a third-party service such as croneos or LiquidApps scheduler.

1 Answer 1


I have had the same problem and there is a solution.

What you have to do is sign the transaction independently from pushing it. For this you have to either have the private key as a part of your script, or better still store it as an environmental variable so as to not risk having it appear in your repository by mistake.

Then in your script you will do the following steps:

  1. Create the transaction
  2. Sign and push the transaction to the chain

Create the transaction

To create the transaction, you type the normal cleos command into the script, followed by -x 600 -s -d -j > transaction.json, for example:

cleos push action mycontract myaction '[DATA HERE]' -p myaccount -x 600 -s -d -j > transaction.json

This will create a file called transaction.json that contains the action you want to run.

Sign and push the transaction

To sign and push the transaction to the chain, you type the following:

cleos sign transaction.json -k PRIVATE_KEY_HERE -p

This will then sign the transaction and push it to the chain.

A word of warning with keys

Obviously, storing your key in any unencrypted way on your server is a risk. This is just a basic example to show you roughly how you could do it. Its up to you to decide what risks are acceptable, and add appropriate measures to protect your key beyond this.

If you are using this cron job to run a non-critical task, I recommend you set up a new key and bind the appropriate action to that key, instead of using the active or owner key. This way, if your server is compromised and the key is stolen, they will only be able to call this single action.

  • Thank you ever so much Phillip. I'll give this a go tomorrow morning (it's midnight here in NZ) and mark it as accepted then.
    – tommccann
    Jan 2, 2021 at 10:54
  • No problem! And thank you for accepting the answer Jan 2, 2021 at 11:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.