0

I have a pine64 (aarch64)

I have set a pruned node.

My user name is pine, when I start the node using bitcoind -daemon I can use bitcoin-cli without problem and the RPC calls are OK.

I want to set in crontab the automatic start of the node if it is rebooted the pine64.

I set crontab as follows

pine@pine64:~$ crontab -e

# m h  dom mon dow   command

@reboot /usr/local/bin/bitcoind &

My bitcoin.conf is this:

pine@pine64:~$ cat .bitcoin/bitcoin.conf 
##
## bitcoin.conf configuration file. Lines beginning with # are comments.
##

# Network-related settings:

# Run on the test network instead of the real bitcoin network.
#testnet=0

# Run a regression test network
#regtest=0

# Connect via a SOCKS5 proxy
#proxy=127.0.0.1:9050

# Bind to given address and always listen on it. Use [host]:port notation for IPv6
#bind=<addr>

# Bind to given address and whitelist peers connecting to it. Use [host]:port notation for IPv6
#whitebind=<addr>

##############################################################
##            Quick Primer on addnode vs connect            ##
##  Let's say for instance you use addnode=4.2.2.4          ##
##  addnode will connect you to and tell you about the      ##
##    nodes connected to 4.2.2.4.  In addition it will tell ##
##    the other nodes connected to it that you exist so     ##
##    they can connect to you.                              ##
##  connect will not do the above when you 'connect' to it. ##
##    It will *only* connect you to 4.2.2.4 and no one else.##
##                                                          ##
##  So if you're behind a firewall, or have other problems  ##
##  finding nodes, add some using 'addnode'.                ##
##                                                          ##
##  If you want to stay private, use 'connect' to only      ##
##  connect to "trusted" nodes.                             ##
##                                                          ##
##  If you run multiple nodes on a LAN, there's no need for ##
##  all of them to open lots of connections.  Instead       ##
##  'connect' them all to one node that is port forwarded   ##
##  and has lots of connections.                            ##
##       Thanks goes to [Noodle] on Freenode.               ##
##############################################################

# Use as many addnode= settings as you like to connect to specific peers
#addnode=69.164.218.197
#addnode=10.0.0.2:8333

# Alternatively use as many connect= settings as you like to connect ONLY to specific peers
#connect=69.164.218.197
#connect=10.0.0.1:8333

# Listening mode, enabled by default except when 'connect' is being used
#listen=1

# Maximum number of inbound+outbound connections.
#maxconnections=

#
# JSON-RPC options (for controlling a running Bitcoin/bitcoind process)
#

# server=1 tells Bitcoin-Qt and bitcoind to accept JSON-RPC commands
#server=0

# Bind to given address to listen for JSON-RPC connections. Use [host]:port notation for IPv6.
# This option can be specified multiple times (default: bind to all interfaces)
#rpcbind=<addr>

# If no rpcpassword is set, rpc cookie auth is sought. The default `-rpccookiefile` name
# is .cookie and found in the `-datadir` being used for bitcoind. This option is typically used
# when the server and client are run as the same user.
#
# If not, you must set rpcuser and rpcpassword to secure the JSON-RPC api. The first
# method(DEPRECATED) is to set this pair for the server and client:
#rpcuser=Ulysseys
#rpcpassword=YourSuperGreatPasswordNumber_DO_NOT_USE_THIS_OR_YOU_WILL_GET_ROBBED_385593
#
# The second method `rpcauth` can be added to server startup argument. It is set at initialization time
# using the output from the script in share/rpcuser/rpcuser.py after providing a username:
#
# ./share/rpcuser/rpcuser.py alice
# String to be appended to bitcoin.conf:
# rpcauth=alice:f7efda5c189b999524f151318c0c86$d5b51b3beffbc02b724e5d095828e0bc8b2456e9ac8757ae3211a5d9b16a22ae
# Your password:
# DONT_USE_THIS_YOU_WILL_GET_ROBBED_8ak1gI25KFTvjovL3gAM967mies3E=
#
# On client-side, you add the normal user/password pair to send commands:
#rpcuser=alice
#rpcpassword=DONT_USE_THIS_YOU_WILL_GET_ROBBED_8ak1gI25KFTvjovL3gAM967mies3E=
#
# You can even add multiple entries of these to the server conf file, and client can use any of them:
# rpcauth=bob:b2dd077cb54591a2f3139e69a897ac$4e71f08d48b4347cf8eff3815c0e25ae2e9a4340474079f55705f40574f4ec99

# How many seconds bitcoin will wait for a complete RPC HTTP request.
# after the HTTP connection is established. 
#rpcclienttimeout=30

# By default, only RPC connections from localhost are allowed.
# Specify as many rpcallowip= settings as you like to allow connections from other hosts,
# either as a single IPv4/IPv6 or with a subnet specification.

# NOTE: opening up the RPC port to hosts outside your local trusted network is NOT RECOMMENDED,
# because the rpcpassword is transmitted over the network unencrypted.

# server=1 tells Bitcoin-Qt to accept JSON-RPC commands.
# it is also read by bitcoind to determine if RPC should be enabled 
#rpcallowip=10.1.1.34/255.255.255.0
#rpcallowip=1.2.3.4/24
#rpcallowip=2001:db8:85a3:0:0:8a2e:370:7334/96

# Listen for RPC connections on this TCP port:
#rpcport=8332

# You can use Bitcoin or bitcoind to send commands to Bitcoin/bitcoind
# running on another host using this option:
#rpcconnect=127.0.0.1

# Create transactions that have enough fees so they are likely to begin confirmation within n blocks (default: 6).
# This setting is over-ridden by the -paytxfee option.
#txconfirmtarget=n

# Miscellaneous options

# Pre-generate this many public/private key pairs, so wallet backups will be valid for
# both prior transactions and several dozen future transactions.
#keypool=100

# Pay an optional transaction fee every time you send bitcoins.  Transactions with fees
# are more likely than free transactions to be included in generated blocks, so may
# be validated sooner.
#paytxfee=0.00

# Enable pruning to reduce storage requirements by deleting old blocks. 
# This mode is incompatible with -txindex and -rescan.
# 0 = default (no pruning).
# 1 = allows manual pruning via RPC.
# >=550 = target to stay under in MiB. 
prune=1000

# User interface options

# Start Bitcoin minimized
#min=1

# Minimize to the system tray
#minimizetotray=1

Now, when the pine64 get rebooted the node starts but the RPC calls are not working, I get this error:

pine@pine64:~$ bitcoin-cli getconnectioncount
error: couldn't connect to server: unknown (code -1)
(make sure server is running and you are connecting to the correct RPC port)

EDIT: I have checked with top and both are under the same user "pine". The one started with crontab after reboot and the one I started using bitcoind -daemon

  • ps results when bitcoin -daemon is executed from cli

pine@pine64:~$ ps aux | grep bitcoind 
pine      2214  9.9 22.6 1862152 461952 ?      Ssl  Oct31  95:02 bitcoind -daemon
pine     26429  0.0  0.0 121620   908 pts/0    S+   11:53   0:00 grep --color=auto bitcoind
  • ps results when bitcoin is executed after reboot in crontab

pine@pine64:~$ ps aux | grep bitcoind
pine       636 65.8 11.3 841216 230304 ?       DLl  11:56   0:11 /usr/local/bin/bitcoind
pine      1073  0.0  0.0 121620   904 pts/0    S+   11:57   0:00 grep --color=auto bitcoind

What am I missing in crontab?

Do I need to set RPC username and password? I rather not.

Thanks

  • 1
    I cannot provide the exact answer, but normally you say you have the user "pine", and everything works. When starting from your crontab, not. I guess the daemon should have the same "home dir" and user rights as "pine", which is not covered in your crontab. Look at the process, who is the owner of the bitcoin daemon, when running from crontab, and when running under "pine"... if you found it, you may want to put your answer below. – pebwindkraft Oct 30 '17 at 22:06
  • Hi @pebwindkraft I have checked with top and both are under the same user "pine". The one started with crontab after reboot and the one I started using bitcoind -daemon – miguelmorales85 Oct 31 '17 at 19:54
  • hmm, so the process is running. Do a netstat -an to see if a process is listening on port 8333. And something which comes to my mind: maybe a cd to pine's home dir before, and see that PATH variables are the same. Or vice versa: use the pine user, and cd into /tmp, start bitcoind -daemon, and see if it works. – pebwindkraft Oct 31 '17 at 20:21
  • I think I've found the problem but I need your help to confirm my doubt. First of all, I have check netstat and found 8333 currently is on listening mode. Then I have checked PATH using printenv PATH=/home/pine/bin:/home/pine/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games is the result There is not a folder /home/pine/bin so I did a ls -la /usr/local/bin/ and got -rwxr-xr-x 1 root root 2615992 Oct 28 21:54 bitcoin-cli So , does that means when bitcoind after a reboot is being executed by user root? – miguelmorales85 Nov 1 '17 at 11:01
  • no, it is not executed as root, the listing ("ls -l") just says, it belongs to root, and anyone can execute it (the "x" in -rwxr-xr-x). It would still run as user "pine", as you confirmed in your 1st comment (when checking with top). btw: "ps aux" is probably the better way to do it. From what you posted, the bitcoin.conf file is in /home/pine/.bitcoin. Folder /home/pine/bin is not required, cause executable is in /usr/local/bin. Can you do a pwd (print working directory) in front of the crontab call? If this doesn't help I need to re-activate my Raspberry. It has SuSE, but should be the same. – pebwindkraft Nov 1 '17 at 11:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.