idea to explore : bundle ntp

[Gr33nDrag0n69]

Bundle ntp client in lisk package with real time sync settings to mitigate forking

[Gr33nDrag0n69]

didn't thinked about the fact ntp is udp 123
maybe a deal breaker

[tracphil]

Absolutely not. Maybe add a check to make sure you have an ntp client installed. ntp on Debian based distros and chrony on Red Hat based distro's.

[Gr33nDrag0n69]

The title is "idea to explore", because I'm not sure it's a good idea and/or it's do-able. I must say I didn't new about chrony and just read about it. I understand your point of saying I want to use what already in my os. I would still use ntp anyway in iburst mode with a couple of predefine servers. I've seen lots of production servers on centos using exactly that to make sure the time is always less then 0.02 secs drifted for credit card transaction. the check is not made once a day but almost in real time. Not sure best way to deal with that maybe a usentp=false in config.json for poeple that have their own custom solution

[Gr33nDrag0n69]

I also understand the concern about lisk is a software and we don't want a "LiskOS" ...

[Isabello]

Even software has dependencies. You can't expect a transactional database which directly relies on proper time to function in sync with other nodes if its not near the same time stamp.

Time synchronization should be considered a base requirement, just like having the ability to untar or unzip files during installation.

[tracphil]

I like this idea:

usentp=false in config.json for poeple that have their own custom solution

[punkrock]

First step should be to add an "how to install ntp" for every installation-tutorial in our documentation. For Ubuntu 16.04 i used:

sudo apt-get install ntpdate
sudo apt-get install ntp
sudo service ntp stop
sudo nano /etc/ntp.conf

Added these lines into my conf-file:
server ntp1.hetzner.de iburst
server ntp2.hetzner.com iburst
server ntp3.hetzner.net iburst
server 0.de.pool.ntp.org
server 1.de.pool.ntp.org
server 2.de.pool.ntp.org
server 3.de.pool.ntp.org

Notice: It was absolutely necessary to have server instead of pool in every line. Otherwise the ntp service didn't start after rebooting my server, because it couldn't connect to the servers.

Start ntp service
sudo service ntp start

If the time is sync, set the hardware clock to the current system time
sudo hwclock --systohc

Additional thoughts: Maybe it's possible to check all nodes on their time and if one is wrong, it gets banned. Dunno if this is possible. I read this solution: http://unix.stackexchange.com/questions/18642/how-to-check-if-ntpd-updates-machines-time-successfully-using-shell/18682#18682

[mrv777]

I added a pull request to at least give a status check if the ntp service is running on a debian based system. It's not perfect and doesn't verify if the service is even working properly, but it's a quick/easy check to help for now

[TheGoldenEye]

One remark.
The solutions mentioned here do not work in OpenVZ virtual environments (VE). In a OpenVZ VE you can install ntd or ntpdate, but it will not work. It is not possible to run ntpd nor ntpdate (I'm not sure, I think it was a permission error). The VE can't set the time, because it is set by the host.
BTW, the time is typically right set.
The said above does not apply to KVM or other VEs. There the time should set inside the VE.

[mrv777]

That's true GoldenEye.
As a more complex solution, I wonder if its possible to have peers announce their current UTC time too with their other information? If a peer differs from you by too much, they get banned for 60 minutes.
As a side effect (whether good or bad), I'm guessing very slow peers will also get banned.

[tracphil]

Guys, this is every day hum drum Unix work. Time just works when setup properly. I don't think we should go around banning people. That doesn't seem like a good solution at all.

I do wish there were more experienced Linux users being delegates though or have a Windows client for them to click and install.

[Isabello]

I'm looking at addressing this issue in a new provisioning technology for binary installs. The check inside of lisk.sh may not be needed with the implementation since it will be front loaded when deploying lisk.

[Isabello]

This issue can be closed, it was addressed in a change to lisk-build.