How does date command interact with timedatectl?
![Creative The name of the picture](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgO9GURib1T8z7lCwjOGLQaGtrueEthgQ8LO42ZX8cOfTqDK4jvDDpKkLFwf2J49kYCMNW7d4ABih_XCb_2UXdq5fPJDkoyg7-8g_YfRUot-XnaXkNYycsNp7lA5_TW9td0FFpLQ2APzKcZ/s1600/1.jpg)
![Creative The name of the picture](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhYQ0N5W1qAOxLP7t7iOM6O6AzbZnkXUy16s7P_CWfOb5UbTQY_aDsc727chyphenhyphen5W4IppVNernMMQeaUFTB_rFzAd95_CDt-tnwN-nBx6JyUp2duGjPaL5-VgNO41AVsA_vu30EJcipdDG409/s400/Clash+Royale+CLAN+TAG%2523URR8PPP.png)
up vote
1
down vote
favorite
I have two 16.04 servers. The timedatectl
on both machines shows that network time is ON, and NTP is synchronised. Both are using UTC. I then set the date to a random day next month using the date
command.
On the first server, subsequent invocations of date
show that the time change has indeed taken effect. The timedatectl
also shows the new date. Network time is still on, but NTP synchronised = No.
On the second server, subsequent invocations of date
do not show the new time, and neither does timedatectl
. Network time is still on, and so is NTP synchronised.
How does that work? How should it work?
On both machines I did an ps -la | grep ntp
to see if something else was managing the time, but nothing showed up.
The machine that accepts the new date and does not re-synch is running in virtual box, but I have guest additions installed so I imagine that would be compatible with NTP synch. I am not sure about the details of the other machine - it is a Laravel Forge machine.
16.04 time
add a comment |Â
up vote
1
down vote
favorite
I have two 16.04 servers. The timedatectl
on both machines shows that network time is ON, and NTP is synchronised. Both are using UTC. I then set the date to a random day next month using the date
command.
On the first server, subsequent invocations of date
show that the time change has indeed taken effect. The timedatectl
also shows the new date. Network time is still on, but NTP synchronised = No.
On the second server, subsequent invocations of date
do not show the new time, and neither does timedatectl
. Network time is still on, and so is NTP synchronised.
How does that work? How should it work?
On both machines I did an ps -la | grep ntp
to see if something else was managing the time, but nothing showed up.
The machine that accepts the new date and does not re-synch is running in virtual box, but I have guest additions installed so I imagine that would be compatible with NTP synch. I am not sure about the details of the other machine - it is a Laravel Forge machine.
16.04 time
I answered most of this, but your laravel forge machine is a bit unknown. would be good to print out what exactly happens on there when you runsudo date -s ...
to set the system time.
â dpb
Apr 20 at 5:42
add a comment |Â
up vote
1
down vote
favorite
up vote
1
down vote
favorite
I have two 16.04 servers. The timedatectl
on both machines shows that network time is ON, and NTP is synchronised. Both are using UTC. I then set the date to a random day next month using the date
command.
On the first server, subsequent invocations of date
show that the time change has indeed taken effect. The timedatectl
also shows the new date. Network time is still on, but NTP synchronised = No.
On the second server, subsequent invocations of date
do not show the new time, and neither does timedatectl
. Network time is still on, and so is NTP synchronised.
How does that work? How should it work?
On both machines I did an ps -la | grep ntp
to see if something else was managing the time, but nothing showed up.
The machine that accepts the new date and does not re-synch is running in virtual box, but I have guest additions installed so I imagine that would be compatible with NTP synch. I am not sure about the details of the other machine - it is a Laravel Forge machine.
16.04 time
I have two 16.04 servers. The timedatectl
on both machines shows that network time is ON, and NTP is synchronised. Both are using UTC. I then set the date to a random day next month using the date
command.
On the first server, subsequent invocations of date
show that the time change has indeed taken effect. The timedatectl
also shows the new date. Network time is still on, but NTP synchronised = No.
On the second server, subsequent invocations of date
do not show the new time, and neither does timedatectl
. Network time is still on, and so is NTP synchronised.
How does that work? How should it work?
On both machines I did an ps -la | grep ntp
to see if something else was managing the time, but nothing showed up.
The machine that accepts the new date and does not re-synch is running in virtual box, but I have guest additions installed so I imagine that would be compatible with NTP synch. I am not sure about the details of the other machine - it is a Laravel Forge machine.
16.04 time
edited Apr 25 at 23:18
asked Apr 19 at 22:52
Kim Prince
181212
181212
I answered most of this, but your laravel forge machine is a bit unknown. would be good to print out what exactly happens on there when you runsudo date -s ...
to set the system time.
â dpb
Apr 20 at 5:42
add a comment |Â
I answered most of this, but your laravel forge machine is a bit unknown. would be good to print out what exactly happens on there when you runsudo date -s ...
to set the system time.
â dpb
Apr 20 at 5:42
I answered most of this, but your laravel forge machine is a bit unknown. would be good to print out what exactly happens on there when you run
sudo date -s ...
to set the system time.â dpb
Apr 20 at 5:42
I answered most of this, but your laravel forge machine is a bit unknown. would be good to print out what exactly happens on there when you run
sudo date -s ...
to set the system time.â dpb
Apr 20 at 5:42
add a comment |Â
2 Answers
2
active
oldest
votes
up vote
0
down vote
You are asking a lot of good questions, I'll try to answer them, but I also suggest you read this unix.stackexchange q/a on time on linux. It should provide you with some more in depth background than just the specific questions you are asking.
Some Background Info
timedatectl
is a program to interact with systemd-timesyncd
, which is a lightweight NTP client provided by systemd
. Run man timedatectl
to get an easy-to-read description of the program. For instance Network time on: yes
just means that the systemd-timesyncd
service is enabled. That's it.
This also explains why you won't see ps faux |grep ntp
return anything.
The built-in ntp client is called systemd-timesyncd
.
date
is a program to query and manipulate the system date and time. This is the time that your operating system thinks it is right now. If you ran this with the -s
argument, it will allow you to adjust your system time
About your sample machines
machine-1 you said is a machine running virtualbox. This allows you setting the system clock normally (and even has a virtual hardware clock for you to mess with if you want).
What you describe sounds normal, you have skewed the clock a day, and the ntp client will no longer sync correctly. This is why the ntpdate
command existed for a long time in ubuntu, it's a one time command to bring the clock into alignment, and hand it over to an ntp client. systemd-timesyncd
now has this functionality built-in, but it only runs at startup, not all the time.
machine-2 you said is a laravel forge machine. I'm not sure what that is specifically. If you run sudo date -s '2018-04-18 12:00:00'
, does it let you do it? What does it say? It could be you don't have the ability to change the system clock on that server. It could be a container (docker, lxd) of some kind, for instance.
add a comment |Â
up vote
0
down vote
On the second server (where I was unable to change the date), issuing sudo timedatectl set-ntp off
fixes the problem. Later, when I want to re-synch the time, I issue sudo timedatectl set-ntp on
and give it a few moments. This makes sense.
add a comment |Â
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
0
down vote
You are asking a lot of good questions, I'll try to answer them, but I also suggest you read this unix.stackexchange q/a on time on linux. It should provide you with some more in depth background than just the specific questions you are asking.
Some Background Info
timedatectl
is a program to interact with systemd-timesyncd
, which is a lightweight NTP client provided by systemd
. Run man timedatectl
to get an easy-to-read description of the program. For instance Network time on: yes
just means that the systemd-timesyncd
service is enabled. That's it.
This also explains why you won't see ps faux |grep ntp
return anything.
The built-in ntp client is called systemd-timesyncd
.
date
is a program to query and manipulate the system date and time. This is the time that your operating system thinks it is right now. If you ran this with the -s
argument, it will allow you to adjust your system time
About your sample machines
machine-1 you said is a machine running virtualbox. This allows you setting the system clock normally (and even has a virtual hardware clock for you to mess with if you want).
What you describe sounds normal, you have skewed the clock a day, and the ntp client will no longer sync correctly. This is why the ntpdate
command existed for a long time in ubuntu, it's a one time command to bring the clock into alignment, and hand it over to an ntp client. systemd-timesyncd
now has this functionality built-in, but it only runs at startup, not all the time.
machine-2 you said is a laravel forge machine. I'm not sure what that is specifically. If you run sudo date -s '2018-04-18 12:00:00'
, does it let you do it? What does it say? It could be you don't have the ability to change the system clock on that server. It could be a container (docker, lxd) of some kind, for instance.
add a comment |Â
up vote
0
down vote
You are asking a lot of good questions, I'll try to answer them, but I also suggest you read this unix.stackexchange q/a on time on linux. It should provide you with some more in depth background than just the specific questions you are asking.
Some Background Info
timedatectl
is a program to interact with systemd-timesyncd
, which is a lightweight NTP client provided by systemd
. Run man timedatectl
to get an easy-to-read description of the program. For instance Network time on: yes
just means that the systemd-timesyncd
service is enabled. That's it.
This also explains why you won't see ps faux |grep ntp
return anything.
The built-in ntp client is called systemd-timesyncd
.
date
is a program to query and manipulate the system date and time. This is the time that your operating system thinks it is right now. If you ran this with the -s
argument, it will allow you to adjust your system time
About your sample machines
machine-1 you said is a machine running virtualbox. This allows you setting the system clock normally (and even has a virtual hardware clock for you to mess with if you want).
What you describe sounds normal, you have skewed the clock a day, and the ntp client will no longer sync correctly. This is why the ntpdate
command existed for a long time in ubuntu, it's a one time command to bring the clock into alignment, and hand it over to an ntp client. systemd-timesyncd
now has this functionality built-in, but it only runs at startup, not all the time.
machine-2 you said is a laravel forge machine. I'm not sure what that is specifically. If you run sudo date -s '2018-04-18 12:00:00'
, does it let you do it? What does it say? It could be you don't have the ability to change the system clock on that server. It could be a container (docker, lxd) of some kind, for instance.
add a comment |Â
up vote
0
down vote
up vote
0
down vote
You are asking a lot of good questions, I'll try to answer them, but I also suggest you read this unix.stackexchange q/a on time on linux. It should provide you with some more in depth background than just the specific questions you are asking.
Some Background Info
timedatectl
is a program to interact with systemd-timesyncd
, which is a lightweight NTP client provided by systemd
. Run man timedatectl
to get an easy-to-read description of the program. For instance Network time on: yes
just means that the systemd-timesyncd
service is enabled. That's it.
This also explains why you won't see ps faux |grep ntp
return anything.
The built-in ntp client is called systemd-timesyncd
.
date
is a program to query and manipulate the system date and time. This is the time that your operating system thinks it is right now. If you ran this with the -s
argument, it will allow you to adjust your system time
About your sample machines
machine-1 you said is a machine running virtualbox. This allows you setting the system clock normally (and even has a virtual hardware clock for you to mess with if you want).
What you describe sounds normal, you have skewed the clock a day, and the ntp client will no longer sync correctly. This is why the ntpdate
command existed for a long time in ubuntu, it's a one time command to bring the clock into alignment, and hand it over to an ntp client. systemd-timesyncd
now has this functionality built-in, but it only runs at startup, not all the time.
machine-2 you said is a laravel forge machine. I'm not sure what that is specifically. If you run sudo date -s '2018-04-18 12:00:00'
, does it let you do it? What does it say? It could be you don't have the ability to change the system clock on that server. It could be a container (docker, lxd) of some kind, for instance.
You are asking a lot of good questions, I'll try to answer them, but I also suggest you read this unix.stackexchange q/a on time on linux. It should provide you with some more in depth background than just the specific questions you are asking.
Some Background Info
timedatectl
is a program to interact with systemd-timesyncd
, which is a lightweight NTP client provided by systemd
. Run man timedatectl
to get an easy-to-read description of the program. For instance Network time on: yes
just means that the systemd-timesyncd
service is enabled. That's it.
This also explains why you won't see ps faux |grep ntp
return anything.
The built-in ntp client is called systemd-timesyncd
.
date
is a program to query and manipulate the system date and time. This is the time that your operating system thinks it is right now. If you ran this with the -s
argument, it will allow you to adjust your system time
About your sample machines
machine-1 you said is a machine running virtualbox. This allows you setting the system clock normally (and even has a virtual hardware clock for you to mess with if you want).
What you describe sounds normal, you have skewed the clock a day, and the ntp client will no longer sync correctly. This is why the ntpdate
command existed for a long time in ubuntu, it's a one time command to bring the clock into alignment, and hand it over to an ntp client. systemd-timesyncd
now has this functionality built-in, but it only runs at startup, not all the time.
machine-2 you said is a laravel forge machine. I'm not sure what that is specifically. If you run sudo date -s '2018-04-18 12:00:00'
, does it let you do it? What does it say? It could be you don't have the ability to change the system clock on that server. It could be a container (docker, lxd) of some kind, for instance.
answered Apr 20 at 5:41
dpb
4,90911545
4,90911545
add a comment |Â
add a comment |Â
up vote
0
down vote
On the second server (where I was unable to change the date), issuing sudo timedatectl set-ntp off
fixes the problem. Later, when I want to re-synch the time, I issue sudo timedatectl set-ntp on
and give it a few moments. This makes sense.
add a comment |Â
up vote
0
down vote
On the second server (where I was unable to change the date), issuing sudo timedatectl set-ntp off
fixes the problem. Later, when I want to re-synch the time, I issue sudo timedatectl set-ntp on
and give it a few moments. This makes sense.
add a comment |Â
up vote
0
down vote
up vote
0
down vote
On the second server (where I was unable to change the date), issuing sudo timedatectl set-ntp off
fixes the problem. Later, when I want to re-synch the time, I issue sudo timedatectl set-ntp on
and give it a few moments. This makes sense.
On the second server (where I was unable to change the date), issuing sudo timedatectl set-ntp off
fixes the problem. Later, when I want to re-synch the time, I issue sudo timedatectl set-ntp on
and give it a few moments. This makes sense.
answered Apr 21 at 21:23
Kim Prince
181212
181212
add a comment |Â
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
var $window = $(window),
onScroll = function(e)
var $elem = $('.new-login-left'),
docViewTop = $window.scrollTop(),
docViewBottom = docViewTop + $window.height(),
elemTop = $elem.offset().top,
elemBottom = elemTop + $elem.height();
if ((docViewTop elemBottom))
StackExchange.using('gps', function() StackExchange.gps.track('embedded_signup_form.view', location: 'question_page' ); );
$window.unbind('scroll', onScroll);
;
$window.on('scroll', onScroll);
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f1026543%2fhow-does-date-command-interact-with-timedatectl%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
var $window = $(window),
onScroll = function(e)
var $elem = $('.new-login-left'),
docViewTop = $window.scrollTop(),
docViewBottom = docViewTop + $window.height(),
elemTop = $elem.offset().top,
elemBottom = elemTop + $elem.height();
if ((docViewTop elemBottom))
StackExchange.using('gps', function() StackExchange.gps.track('embedded_signup_form.view', location: 'question_page' ); );
$window.unbind('scroll', onScroll);
;
$window.on('scroll', onScroll);
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
var $window = $(window),
onScroll = function(e)
var $elem = $('.new-login-left'),
docViewTop = $window.scrollTop(),
docViewBottom = docViewTop + $window.height(),
elemTop = $elem.offset().top,
elemBottom = elemTop + $elem.height();
if ((docViewTop elemBottom))
StackExchange.using('gps', function() StackExchange.gps.track('embedded_signup_form.view', location: 'question_page' ); );
$window.unbind('scroll', onScroll);
;
$window.on('scroll', onScroll);
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
var $window = $(window),
onScroll = function(e)
var $elem = $('.new-login-left'),
docViewTop = $window.scrollTop(),
docViewBottom = docViewTop + $window.height(),
elemTop = $elem.offset().top,
elemBottom = elemTop + $elem.height();
if ((docViewTop elemBottom))
StackExchange.using('gps', function() StackExchange.gps.track('embedded_signup_form.view', location: 'question_page' ); );
$window.unbind('scroll', onScroll);
;
$window.on('scroll', onScroll);
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
I answered most of this, but your laravel forge machine is a bit unknown. would be good to print out what exactly happens on there when you run
sudo date -s ...
to set the system time.â dpb
Apr 20 at 5:42