7

I know parity can run as a daemon because the --help has a usage parity daemon <pid-file> [options] but no further help/clues/documentation is provided. What is <pid-file> ? A process ID file, and what is that? If it is supposed to be a systemd unit file why doesn't it say so.

The only other clue I can find after searching and searching is this: https://daowiki.atlassian.net/wiki/display/DAO/Ethereum+network It says to edit the parity.service and parity.conf file, however both of those do not exist. I can try creating them but then why is there NOTHING when googling on this. I can't be the first and only person on this planet to want to run parity as a daemon. (I don't want this question to sound negative. I really appreciate the great contribution the ethcore team and their parity project has given to the Ethereum community!)

Ubuntu 16.04
parity v1.2.2

2

TL;DR - it's just a path to an empty file of your choice, and prevents multiple instances of the daemon from running. (I don't think the file even needs to exist - it will be created for you.)


Parity uses the general Rust implementation of daemonize(), which itself takes a pid_file argument.

Taking things one step further, the Rust implementation is based on Python's daemonize library, which again uses the same idea.

The basic idea is to prevent multiple versions of your script/program running at the same time. Your pid_file argument is just a path to a file where the pid will be stored, which at first will be empty, but which will be written to by the running program.

  • When the script starts, the first thing it does it look for a file (wherever you've put it - probably something like /tmp/parity_daemon.pid);
  • If that file exists, then the script reads a pid from it. The script now checks if any process with that pid is already running. (Note that the pid file should be cleaned up when the daemon gracefully exits, but it's possible the daemon crashed on its last run, so the pid file still exists.);
  • If there is a process running with that pid, then there is already a running instance of this program/daemon, so the new daemon instance should exit.
1

I recommend using an init system (systemd, SysV, upstart) to manage the Parity process. Here I will provide an example using systemd, and additional resources are listed at the end.


First, define the service in a systemd unit file:

cat <<EOF | sudo tee /etc/systemd/system/parity.service
[Unit]
Description=Parity Ethereum client
Documentation=https://wiki.parity.io
After=network.target

[Service]
Type=simple
ExecStart=/usr/bin/parity
Restart=on-failure
# SIGHUP gives parity time to exit cleanly before SIGKILL
KillSignal=SIGHUP

[Install]
WantedBy=multi-user.target
Alias=parity.service
EOF

We want to avoid an unclean shutdown of the parity process, because that can cause database corruption. To accomplish this we override the default KillSignal, so SIGHUP (equivalent to ctrl-c) is sent first. After 90 seconds (by default), if the process is still running, then SIGKILL would be sent.

You may also want to modify the ExecStart parameter to include additional options.

After the service is defined we can reload the definitions from disk:

sudo systemctl daemon-reload

Enable the service, so it starts automatically after a reboot:

sudo systemctl enable parity

And, finally, start the service:

sudo systemctl start parity

Another thing to note is Restart=on-failure. This will automatically restart the process when it dies (including if you manually kill it).

To stop Parity, use:

sudo systemctl stop parity

To check the status, use:

systemctl status parity

You can also follow logs with journald:

journalctl -f -u parity.service

Note that init services provide a lot of flexibility, and this is only a simple example using systemd, which is now the most common. For additional reading, visit these resources:

  • don't forget to use sudo loginctl enable-linger username if using systemctl --user enable /path/to/parity.service to prevent stopping parity when user logs out – GViz Jun 2 '18 at 2:47
  • @thinkmassive I am using this solution because the parity docker solution was working but there were no folders getting created. So I did know where was all the chaindata, keys etc going. I used this solution and now Parity is working absolutely fine and I can also use geth to attach to the IPC service. Thank you so much once again. – codestruggle Jul 12 '18 at 8:28
  • Anyone who is reading or implementing this example please do not include the Alias=parity.service as the second last line. It causes problems while enabling the service. Rest everything is fine. – codestruggle Jul 12 '18 at 10:43
0

Since the use case of daemon is similar to screen, I am just suggesting another approach of running parity in background.

  • Start a new screen using screen -s parity. Here the name of the screen is parity.
  • Start the parity in the usual way you start as.
  • Ctrl+A Ctrl+D to detach from screen, parity still runs in background. Even if you logout from server, screen is running and you can come back and visit the screen anytime.
  • You can resume the screen using screen -r
  • screen -ls to see all screens.

Your Answer

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

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