I have problem with dynamically date change inside container. What I have:
docker run -it --privileged myDocker
the command above run container with privilege to change date
I can change date by:
date --set "12-12-12"
but after a few seconds, the date and time are setted the same as the host
root#660acd776c6b:/# date --set "12-12-12"
root#660acd776c6b:/# date
Wed Dec 12 00:00:01 UTC 2012
root#660acd776c6b:/# date
Wed Dec 12 00:00:02 UTC 2012
root#660acd776c6b:/# date
Wed Dec 12 00:00:02 UTC 2012
root#660acd776c6b:/# date
Tue Jan 15 10:14:26 UTC 2019
root#660acd776c6b:/# date
Tue Jan 15 10:14:27 UTC 2019
The container doesn't have installed ntp.
I can't use faketime because I use the date in .net application which doesn't use time from faketime. I can't change system clock using faketime.
How could I disable synchronization between container and host ?
Related
We have a linux system that we are building with yocto.
We can read our hardware clock after reboots, change both system time and hardware time without any error (most of the time). However; after some new month, every year that we have tried we are running in to this error. "hwclock: RTC_RD_TIME: Invalid argument".
Example 1:
root#:~# date
Thu Apr 30 23:59:50 UTC 2020
root#:~# hwclock
Thu Apr 30 23:59:52 2020 0.000000 seconds
root#:~#
root#:~#
root#:~# date
Fri May 1 00:00:10 UTC 2020
root#:~# hwclock
hwclock: RTC_TD_TIME: Invalid argument
root#:~#
This is not happening every new month, if I do the same test in January linux can read the hwclock without any issues. It does also not matter if the unit is powered or not. If I set the hwclock to first of May 00:00:00 it can keep track of the time.
The same error occurs on the following month shift:
Feb (it does not matter if it is leap year or not) -> Mar
Apr -> May
Jun -> Jul
Sep -> Oct
Nov -> Dec
Dec (Not sure because of new year or new month) -> Jan
In my understanding, this is happening because rtc-lib.c cannot verify the time correctly.
I have tried on multiple different hardware
Does anyone have any idea what might cause this?
Solution:
The fault was not in rtc-lib.c. The cause of the error was a faulty RTC implementation. The RTC month value is 1-indexed, but the kernel assumes it is 0-indexed. Added a patch for this to rtc-[my_rtc_model].c and now it seems to be working.
Postgresql is rather good at handling timezones, using the classic tzdata database.
The server can convert past and future timestamps between the different timezones, following the rules in tzdata (offsets, dst changes, ..)
Is there a simple and efficient way, for a given timezone and a given date range, to extract all the timestamps within that range when a timezone modification event occured ?
the result should more or less contain the equivalent of the output of the zdump linux command.
zdump -v /usr/share/zoneinfo/America/Los_Angeles | grep 2017
Sun Mar 12 09:59:59 2017 UTC = Sun Mar 12 01:59:59 2017 PST isdst=0 gmtoff=-28800
Sun Mar 12 10:00:00 2017 UTC = Sun Mar 12 03:00:00 2017 PDT isdst=1 gmtoff=-25200
Sun Nov 5 08:59:59 2017 UTC = Sun Nov 5 01:59:59 2017 PDT isdst=1 gmtoff=-25200
Sun Nov 5 09:00:00 2017 UTC = Sun Nov 5 01:00:00 2017 PST isdst=0 gmtoff=-28800
select d::date
from (
select
d at time zone 'America/Los_Angeles' as la,
lead(d at time zone 'America/Los_Angeles') over (order by d) as la_,
d
from generate_series (
'2017-01-01'::timestamp,
'2017-12-31', '1 day'
) gs (d)
) s
where la::time <> la_::time;
d
------------
2017-03-12
2017-11-05
I'm trying to snapshot my docker container so that I can revert back to a single point in time.
I've looked at docker save and docker export but neither of these seems to do what I'm looking for. Am I missing something?
You might want to use docker commit. This command will create a new docker image from one of your docker containers. This way you can easily create a new container later on based on that new image.
Be aware that the docker commit command won't save any data stored in Docker data volumes. For those you need to make backups.
For instance if you are working with the following Dockerfile which declares a volume and will write the date every 5 seconds to two files (one being in the volume, the other not):
FROM base
VOLUME /data
CMD while true; do date >> /data/foo.txt; date >> /tmp/bar.txt; sleep 5; done
Build a image from it:
$ docker build --force-rm -t so-26323286 .
and run a new container from it:
$ docker run -d so-26323286
Wait a bit so that the running docker container have a chance to write the date to the two files a couple of times.
$ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
07b094be1bb2 so-26323286:latest "/bin/sh -c 'while t 5 seconds ago Up 5 seconds agitated_lovelace
Then commit your container into a new image so-26323286:snapshot1:
$ docker commit agitated_lovelace so-26323286:snapshot1
You can now see that you have two images availables:
$ docker images | grep so-26323286
so-26323286 snapshot1 03180a816db8 19 seconds ago 175.3 MB
so-26323286 latest 4ffd141d7d6f 9 minutes ago 175.3 MB
Now let's verify that a new container run from so-26323286:snapshot1 would have the /tmp/bar.txt file:
$ docker run --rm so-26323286:snapshot1 cat /tmp/bar.txt
Sun Oct 12 09:00:21 UTC 2014
Sun Oct 12 09:00:26 UTC 2014
Sun Oct 12 09:00:31 UTC 2014
Sun Oct 12 09:00:36 UTC 2014
Sun Oct 12 09:00:41 UTC 2014
Sun Oct 12 09:00:46 UTC 2014
Sun Oct 12 09:00:51 UTC 2014
And witness that such a container does not have any /data/foo.txt file (as /data is a data volume):
$ docker run --rm so-26323286:snapshot1 cat /data/foo.txt
cat: /data/foo.txt: No such file or directory
Finally if you want to access to the /data/foo.txt file which is in the first (still running) container, you can use the docker run --volumes-from option:
$ docker run --rm --volumes-from agitated_lovelace base cat /data/foo.txt
Sun Oct 12 09:00:21 UTC 2014
Sun Oct 12 09:00:26 UTC 2014
Sun Oct 12 09:00:31 UTC 2014
Sun Oct 12 09:00:36 UTC 2014
Sun Oct 12 09:00:41 UTC 2014
Sun Oct 12 09:00:46 UTC 2014
Sun Oct 12 09:00:51 UTC 2014
Sun Oct 12 09:00:56 UTC 2014
Sun Oct 12 09:01:01 UTC 2014
Sun Oct 12 09:01:06 UTC 2014
Sun Oct 12 09:01:11 UTC 2014
Sun Oct 12 09:01:16 UTC 2014
Here is an example of how to do it with the hello-world image from Docker Hub
First run the hello-world image, thereby downloading the image:
docker run hello-world
Then get the hash of the image you want to get the has of
docker history hello-world
You will see something like:
IMAGE CREATED
fce289e99eb9 15 months ago
fce289e99eb9 is your hash-code.
To tag this image, you run:
docker tag fce289e99eb9 hello-world:SNAPSHOT-1.0
To list all the tags for a repository, use:
docker image ls hello-world
And you will get something like:
REPOSITORY TAG IMAGE ID CREATED SIZE
hello-world SNAPSHOT-1.0 fce289e99eb9 15 months ago 1.84kB
hello-world latest fce289e99eb9 15 months ago 1.84kB
I don't know how to interpret this date format:
1394862706,
1394862645,
1400258321,
1400258250 etc. (each block is a different date)
Does someone understand in which format are them?
I believe they're Unix timestamps. For example, 1400258250 maps to 4:37:30 May 16 2014. They represent the number of seconds that have elapsed since the Unix epoch, January 1, 1970.
Here's a nice timestamp converter.
As others have noted, the 10-digit numbers are Unix timestamps, the number of seconds since 1970-01-01 00:00:00 +00:00, the Unix Epoch.
If you have GNU date, you can use the -d option (or --date) and the # prefix to analyze them (here, with TZ=US/Pacific or TZ=America/Los_Angeles):
$ for ts in 1394862706 1394862645 1400258321 1400258250; do date -d #$ts; done
Fri Mar 14 22:51:46 PDT 2014
Fri Mar 14 22:50:45 PDT 2014
Fri May 16 09:38:41 PDT 2014
Fri May 16 09:37:30 PDT 2014
$
If you add the -u or --utc option, then you get the output:
Sat Mar 15 05:51:46 UTC 2014
Sat Mar 15 05:50:45 UTC 2014
Fri May 16 16:38:41 UTC 2014
Fri May 16 16:37:30 UTC 2014
I need to use the CLI to see the time in arbitrary timezones. However, Debian doesn't respond to the recommended solution.
First, I set the local timezone.
dpkg-reconfigure tzdata
Then, I set the system time.
ntpdate pool.ntp.org
I update the hardware clock to reflect the system time.
hwclock --systohc --utc
Now, I follow this post:
http://www.linuxquestions.org/questions/programming-9/display-different-timezones-in-command-line-927660/
Which says that I can complete my task using a command such as this:
TZ=UTC date && TZ=CDT date && TZ=IST date
However, this is the output I get:
dpkg-reconfigure tzdata && ntpdate pool.ntp.org && hwclock --systohc --utc && TZ=UTC date && TZ=CDT date && TZ=IST date
Current default time zone: 'America/Chicago'
Local time is now: Tue Apr 16 14:45:29 CDT 2013.
Universal Time is now: Tue Apr 16 19:45:29 UTC 2013.
16 Apr 19:45:38 ntpdate[12036]: adjust time server 199.102.46.73 offset -0.036668 sec
Tue Apr 16 19:45:39 UTC 2013
Tue Apr 16 19:45:39 CDT 2013
Tue Apr 16 19:45:39 IST 2013
CDT and IST aren't valid timezone names, so date is defaulting to show you UTC time if you attempt to use those as your timezone.
I'm not sure which timezones you actually meant to use, but try a couple of these. They are valid timezone names.
TZ=Asia/Shanghai date
TZ=America/Vancouver date
TZ=Europe/London date