Синхронизация времени ubuntu cron
how to use NTP to synchronize the date and time in linux
Most times you want all the servers and machines in the network to be synchronized to the same date and time. This has several advantages, mainly in network related operations. It is also important because many applications on the system uses the machine clock as well.
You can set time and date manually on your Linux system. This works most of the time as you need to set it only once and the clock maintains the correct date and time. But as with most clocks in real world, it is quite possible that your clock will run either slow or fast over a period of time, also known as the clock drift. This can cause the clock to get out of sync with the actual time.
What is NTP
Network Time Protocol or NTP is the network protocol used to effectively transmit and synchronize time across different computers and networks over the internet. It provides accurate time across networks in a consistent format, that can then be used by machines to set their own clocks.
There are several advantages in using NTP to set the date and time on your machine. It maintains the correct date and time without any user intervention. It allows you to maintain the same accurate date and time across several machines in the same network.
NTP works in a hierarchical client-server model. At the top of the hierarchy are Stratum 0 servers or Reference Clocks. Below these reference cloaks are Stratum 1 servers which synchronizes their time with these Reference Clocks. These are the best servers that are available to the public machines over the internet.
You can synchronize your machine with any of the time servers available on the internet, which can be in any stratum, 1 to 16.
You will need to install the NTP if it is not already installed. How you install will depend very much on your Linux distribution, and it should be available in your distribution repository under the name ntp. For Debian/Ubuntu distro variations, use the apt-get as follows
sudo apt-get install ntp
In the Redhat or CentOS variations, you can use yum to install ntp
yum install ntp
if you are on Gentoo, then use emerge as below
emerge -av net-misc/ntp
You will first need to edit the ntp configuration file. This file is located at /etc/ntp.conf on most distros. If you cannot find the file under /etc on your machine, then check the Linux distribution documentation for your machine.
The configuration file specifies the servers that will be contacted to which your machine clock will be synchronized. You can find specific machines for your region from the NTP website. For example, the users in North America can use the servers in the pool: 0.north-america.pool.ntp.org as mentioned in http://www.pool.ntp.org/zone/north-america. The machines in the Asia can point to 0.asia.pool.ntp.org (http://www.pool.ntp.org/zone/asia).
When using a pool, the list of servers that the pool points to changes randomly, usually every hour. This will make sure that you will hit a server that is working and also distribute the load much more evenly.
In addition to using the generic pool, you can use specific pools or servers as well. For example, gentoo users can use the 0.gentoo.pool.ntp.org or can you specify the IP address of a specific server or a machine in your network that supports NTP.
For example, the server setting in your configuration file could be like something shown below:
There is really no other settings that you need to modify out of the box. The default settings will work perfectly in most cases. Once you have installed the ntp, there are a couple of options you have to run it. You can run the ntp client as a cron job or as a service on your machine.
Install as a Cron Job
Instead of installing the ntpd service, you can run the ntpdate command as a cron job to update the time at defined intervals. In order to update the time every day, use the following entry in your cron tab file.
0 0 * * * root ntpdate -s us.pool.ntp.org
It is not a good idea to run it as a cron job for a couple of reasons. If your clock drifts too much between updates, then it causes the clock to jump around quite a bit every time it updates. It also causes unnecessary load on the time servers. Always run NTP as a service when possible.
Install as a Daemon/Service
After installing, you can now synchronize the time on the current machine either manually or run the NTP as a service to synchronize time at specific intervals. To get you up and running, make sure that the current time is set to a reasonable value, something that is close to the actual time.
You can set the date and time manually using the command line using the date command. You can also use the ntpdate command to perform this operation as well.
Running as a service has the added advantage that it uses a drift file. This is used to keep the clock reasonably accurate even when the servers cannot be accessed for a period of time. In order to update the time use the following command from the command prompt.
bash# ntpdate pool.ntp.org
You can now start (or restart) the NTP service to synchronize the clock. This may vary a little based on your operating system, but usually the following will work in most cases.
You can verify that your machine is synchronizing the time by using the ntpq command. It could take a little while to synchronize the first time around, so be patient. From the command line execute the ntpq command with the -p option, as below
This will print out a list of servers, something like what is shown in the example/screenshot below.
Now, in the list of servers verify that one of the remote servers start with an asterisk (*). That is the server that is currently being used to synchronize your clock. Your machine should now have the accurate date and time synchronized to the time servers.
Синхронизация времени ubuntu cron
Authored by: Jered Heeschen
You can easily keep your system’s date and time accurate by using network time protocol (NTP).
Having an accurate clock on your server ensures that timestamps in emails sent from your machine are correct. An accurate clock is especially helpful when you need to look at the logs from a particular time of day.
If you don’t occasionally set the system clock yourself, the time will slowly drift away from a perfectly accurate setting. That’s when NTP is useful.
What is NTP?
NTP lets you automatically sync your system time with a remote server. The NTP can be used to update the clock on a machine with a remote server. This keeps your machine’s time accurate by syncing with servers that are known to have accurate times. NTP also keeps the clocks on several machines in sync, thus making it easier to match log entries for an event across multiple servers.
It’s easy to set up an NTP server to adjust your machine’s clock regularly. It’s also possible to make it a bit more complicated if you need your clock accurate down to the millisecond instead of just to the second.
The first thing to do is to install the NTP server. Grab the package by running:
Ubuntu operating systems / Debian:
Ater you install NTP, you can ensure the service runs at boot time by running the following command:
Fedora / RHEL:
Ater you install NTP, you can ensure the service runs at boot time by running the following command:
Start the service
To make sure the NTP service starts after installing it, run the following command:
Ubuntu operating systems / Debian / CentOS / RHEL:
As is usual for Linux® services, you can stop or restart the NTP service by running the preceding command with stop or restart as the argument instead of start .
Most people just want to get NTP running and don’t need to sync their clock to pinpoint, millisecond-level accuracy. In this case, you don’t need to do anything else. When you installed NTP, it set you up with default servers with which to sync, so NTP syncs your clock automatically. Congratulations on a job well done!
The .ntpconf file
If you want to use NTP to sync several of your own machines, or if you want to choose NTP servers other than the defaults, you can find the NTP configuration file at /etc/ntp.conf.
A few settings can be changed, but the only settings of interest to most users include server entries. Use the default settings for your specific Linux distribution.
With more than one server entry, your NTP server queries all servers and select a time on which most of the polled servers agree. Because NTP uses three or more servers, your clock is more accurate than if it uses only one.
Adding the iBurst option after the server address speeds up the NTP time sync slightly. While this is helpful, it isn’t essential.
The dynamic option tells NTP that it can try a configured server again later if it’s unavailable at some point. The dynamic option is useful when NTP runs on a machine that doesn’t always have access to the Internet. It is not necessary on a machine with a dedicated connection.
Protect yourself against NTP server attacks by adding disable monitor to your /etc/ntp.conf file. Disabling monitoring prevents unwanted remote queries that use commands from older versions of NTP, such as monlist.
Syncing multiple servers
If you have more than one machine to sync, it is best to designate one as the master NTP server. Set up the master server to connect to an outside NTP server, then have the other machines sync to the master. This setup reduces the number of outgoing connections and guarantees that all of your machines have their time set to the same value. This configuration requires changes to the server settings in the ntp.conf files on each machine.
Set up any external servers you want to use on the master machine. For example, if you want to use the NTP pool servers, you can set the server values in the master ntp.conf file to:
Point the ntp.conf to your master server on every other machine that needs to sync the time. For example, if your master server is main.example.com, you would alter the ntp.conf files on the secondary machines so that the server entries are as follows:
After setting the server parameters and ensuring that the iptables entries don’t block connections to your main NTP server, restart the NTP services on each machine to get them syncing.
NTP uses UDP port 123 to conduct its business, either connecting to another NTP server or accepting incoming connections. If you have iptables filtering incoming traffic on the main NTP server in your cluster, you need to open port 123 to UDP traffic to allow the other servers to connect to it. You can open port 123 for UDP traffic with the following iptables arguments:
Choosing an NTP server
When syncing one or more machines via NTP, you want at least one of them to set their time from a reliable external server. Many public servers out there are either synced directly from an atomic clock (guaranteeing an absolutely accurate time) or synced from another server that syncs to an atomic clock.
Public NTP server lists
The best source for lists of public NTP servers is the NTP Servers WebHome at the main NTP site. The site has a description of the servers available, and the sidebar has links to three levels of NTP servers: Primary, secondary, and pool.
Deciding what type of server to sync from depends on how accurate you need your servers to be.
NTP pool servers
For most users, the pool servers are the best choice. Pool servers are machines that have volunteered to make their NTP server available to the public. They typically sync from a secondary NTP server, so their time is accurate, but not necessarily accurate to the nearest millisecond.
Most users don’t need their machine time accurate to the nearest millisecond; they just want to know what time it is. Use the pool servers unless you need pinpoint accuracy.
Using the NTP pool servers is as easy as setting the server entries in your ntp.conf file to:
To ensure that you only connect to pool servers in your own country or region, visit the pool servers page for more specific addresses. For most people, the above entries are more than sufficient. Those addresses rotate among a huge list of volunteer NTP servers worldwide, so the load on any one machine never gets too great.
If you want to contribute to the NTP pool after you’ve set up your NTP server, get details on how to do so from the pool website.
Primary and secondary servers
The other two tiers of NTP servers are primary and secondary servers. A primary server gets its time directly from an atomic clock (or from GPS satellites, which use atomic clocks). Atomic clocks are expensive, so there aren’t many primary servers. You don’t have to use a primary server unless you’re looking for extreme scientific accuracy.
A secondary server usually gets its time from a primary server. If you want accuracy down to the millisecond level, having three secondary servers in your ntp.conf works well.
You can see what public servers are available in either tier by selecting either list from the NTP Servers WebHome. Before selecting and using a server, check the details for that server as follows:
- ISO: The ISO column lists the country of origin of that particular server.
- AccessPolicy: The AccessPolicy field tells you what the access policy is for that server. Open Access means the server can be used by the public, subject to any notification requirements the server has.
- Notify: The Notify field for secondary servers lists the that server administrator’s preferences regarding whether they should be notified before you sync with their NTP server. Admins who want to be notified are usually trying to manage the traffic to their server, so be sure and respect their wishes regarding notification. Note that primary servers are always considered as requesting notification before use.
- Service Area: If you’ve selected a primary or secondary server you want to use, click its hostname in the list to view further details for that server. Among the details listed is the ServiceArea field that describes the geographic or demographic group they intend to serve. If that field is Public, you do not have to be in a particular region to use the server. If they list a more specific service area, be sure to respect the server administrator’s wishes in that regard.
Testing with ntpdate
Before using an external NTP server to sync your time, you should make sure you can actually connect to the server from your machine. Fortunately, there’s a tool for that included with the NTP server called ntpdate .
The ntpdate command syncs your clock with an NTP server. It’s similar to what the NTP server does on a regular basis. The ntpd program is a separate package on Ubuntu® operating systems and Debian®. The other distributions install ntpdate at the time of ntpd installation. To use ntpdate , Ubuntu operating system and Debian users must first install it.
Set your clock to sync at times you specify by using cron to run ntpdate . Otherwise, run the NTP server because it uses less bandwidth and keeps time more accurately by tracking your clock’s drift over time and adjusting accordingly. Use ntpdate for testing purposes only.
The ntpdate command does not run when the NTP server is running. If you run ntpdate and get a response like “the NTP socket is in use,” this means your NTP server is running. Stop it with the appropriate command for your distribution:
Ubuntu operating systems / Debian
CentOS / Fedora / RHEL
You can now run ntpdate with the server you want to sync against as an argument. For example, to tell ntpdate to try and sync with “pool.ntp.org”, run the following command:
When you’re finished testing, remember to restart NTP:
Ubuntu operating systems / Debian
CentOS / Fedora / RHEL
Fortunately, NTP time syncing is pretty easy to do. After you set the time servers and start the NTP service, it does its work quietly in the background.
If NTP has any problems, it logs them to the system log, which you should be checking regularly anyway.
For more details on setting up an NTP server and what options are available, visit the NTP documentation site. If you want to know more about how NTP works, go to the main NTP web site, and all will be revealed.
Share this information:
©2020 Rackspace US, Inc.
Except where otherwise noted, content on this site is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License
Как добавить скрипт в cron
Чтобы задать конкретное время исполнения скрипта в cron, используется следующий синтаксис:
*минута *час *день *месяц *день_недели /путь к файлу
Для обозначения даты и времени используются цифры или * (означает, что нужно выполнять скрипт каждую единицу времени, например, если * заменяется час, то скрипт должен запускаться каждый час, если * используется вместо числового обозначения дня — то каждый день). Путь до файла следует указывать обязательно полностью, начиная с корневого файла.
Пусть, к примеру, наш скрипт cron запускает каждую неделю в среду в 14 часов 45 минут.
45 14 * * 3 /usr/local/ping/todo
Отсчет дней недели начинается понедельника, воскресенье считается седьмым или нулевым днем.
Если вам не важен конкретный момент запуска скрипта, но нужно, чтобы он был выполнен, например, во внерабочее время, можно указать интервал, воспользовавшись знаком -.
Запустим наш скрипт в каждый день недели каждый час в период с 00 до 5 часов утра.
0 00-5 * * * /usr/local/ping/todo
Или просто укажем интервал, через который нужно запускать скрипт. К примеру, каждые 30 минут (интервал обозначается при помощи разделителя /).
Также при запуске cron можно использовать переменные, чтобы запустить скрипт.
- @reboot — только 1 раз в момент загрузки;
- @yearly, @annually — ежегодно;
- @monthly — ежемесячно;
- @weekly — еженедельно;
- @daily, @midnight — ежедневно;
- @hourly — каждый час.
В этом случае команда для запуска нашего скрипта 1 раз в месяц будет выглядеть как
Теперь рассмотрим, как просматривать/получить список заданий, запланированных в списке crontab (это системный файл Linux с табличной структурой, где можно просмотреть все задачи cron, так называемые cron job).
Большинство Cron (например, Vixie-Cron — по умолчанию в Debian/Ubuntu, Cronie — по умолчанию в Fedora, Solaris Cron…) предоставляют список запланированных заданий cron для текущего пользователя через команду:
или для другого пользователя через:
# crontab -u username -l
Кроме того, вы можете посмотреть файлы расписания. Обычно они сохраняются в /var/spool/cron, например, для vcron следующий каталог /var/spool/cron/crontabs содержит все настроенные crontabs всех пользователей, кроме пользователя root. Он также может настраивать задания через общесистемный crontab, который находится в:
Чтобы просмотреть задания cron, выполните следующую команду less:
Пример структуры crontab:
На компьютере это выглядит следующим образом:
В cronie (установлен по умолчанию в Fedora/CentOS, Ubuntu) существует каталог конфигурации в стиле cron.d для системных заданий cron:/etc/cron.d
Как всегда, каталог cron.d упрощает ведение записей конфигурации, которые являются частью разных пакетов.
Для удобства большинство дистрибутивов также предоставляет каталоги, в которых периодически выполняются привязанные/хранимые скрипты, например:
Log Retrieval via CLI
To fetch your app’s most recent logs, use the heroku logs command:
In this example, the output includes log lines from one of the app’s web dynos, the Heroku HTTP router, and one of the app’s workers.
The logs command retrieves 100 log lines by default. You can specify the number of log lines to retrieve (up to a maximum of 1,500 lines) by using the —num (or -n ) option.
Similar to tail -f , real-time tail displays recent logs and leaves the session open for real-time logs to stream in. By viewing a live stream of logs from your app, you can gain insight into the behavior of your live application and debug current problems.
You can tail your logs using —tail (or -t ).
When you are done, press Ctrl+C to return to the prompt.
A real-time tail session is automatically terminated after one hour of inactivity.
The output format of the heroku logs command is as follows:
- Timestamp — The date and time recorded at the time the log line was produced by the dyno or component. The timestamp is in the format specified by RFC5424, and includes microsecond precision.
- Source — All of your app’s dynos (web dynos, background workers, cron) have the source, app . All of Heroku’s system components (HTTP router, dyno manager) have the source, heroku .
- Dyno — The name of the dyno or component that wrote the log line. For example, worker #3 appears as worker.3 , and the Heroku HTTP router appears as router .
- Message — The content of the log line. Lines generated by dynos that exceed 10000 bytes are split into 10000 byte chunks without extra trailing newlines. Each chunk is submitted as a separate log line.
If you only want to fetch logs with a certain source, a certain dyno, or both, you can use the —source (or -s ) and —dyno (or -d ) filtering arguments:
When filtering by dyno, either the base name (e.g., —dyno web ) or the full name (e.g., —dyno web.1 ) can be used.
You can also combine the filtering switches with —tail to get a real-time stream of filtered output.
Log Message Ordering
When you retrieve logs, you might notice that they aren’t always in exact chronological order, especially when multiple components are involved. Logs originate from many sources (router nodes, dynos, etc.) and are assembled into a single log stream by Logplex. Logplex itself uses a distributed architecture to ensure high availability, meaning that log messages might be collected across multiple Logplex nodes and therefore be delivered out of order.
The cron utility runs based on commands specified in a cron table (crontab). Each user, including root, can have a cron file. These files don’t exist by default, but can be created in the /var/spool/cron directory using the crontab -e command that’s also used to edit a cron file (see the script below). I strongly recommend that you not use a standard editor (such as Vi, Vim, Emacs, Nano, or any of the many other editors that are available). Using the crontab command not only allows you to edit the command, it also restarts the crond daemon when you save and exit the editor. The crontab command uses Vi as its underlying editor, because Vi is always present (on even the most basic of installations).
New cron files are empty, so commands must be added from scratch. I added the job definition example below to my own cron files, just as a quick reference, so I know what the various parts of a command mean. Feel free to copy it for your own use.
The crontab command is used to view or edit the cron files.
The first three lines in the code above set up a default environment. The environment must be set to whatever is necessary for a given user because cron does not provide an environment of any kind. The SHELL variable specifies the shell to use when commands are executed. This example specifies the Bash shell. The MAILTO variable sets the email address where cron job results will be sent. These emails can provide the status of the cron job (backups, updates, etc.) and consist of the output you would see if you ran the program manually from the command line. The third line sets up the PATH for the environment. Even though the path is set here, I always prepend the fully qualified path to each executable.
There are several comment lines in the example above that detail the syntax required to define a cron job. I’ll break those commands down, then add a few more to show you some more advanced capabilities of crontab files.
This line in my /etc/crontab runs a script that performs backups for my systems.
This line runs my self-written Bash shell script, rsbu, that backs up all my systems. This job kicks off at 1:01 a.m. (01 01) every day. The asterisks (*) in positions three, four, and five of the time specification are like file globs, or wildcards, for other time divisions; they specify «every day of the month,» «every month,» and «every day of the week.» This line runs my backups twice; one backs up to an internal dedicated backup hard drive, and the other backs up to an external USB drive that I can take to the safe deposit box.
The following line sets the hardware clock on the computer using the system clock as the source of an accurate time. This line is set to run at 5:03 a.m. (03 05) every day.
This line sets the hardware clock using the system time as the source.
I was using the third and final cron job (commented out) to perform a dnf or yum update at 04:25 a.m. on the first day of each month, but I commented it out so it no longer runs.
This line used to perform a monthly update, but I’ve commented it out.
Other scheduling tricks
Now let’s do some things that are a little more interesting than these basics. Suppose you want to run a particular job every Thursday at 3 p.m.:
This line runs mycronjob.sh every Thursday at 3 p.m.
Or, maybe you need to run quarterly reports after the end of each quarter. The cron service has no option for «The last day of the month,» so instead you can use the first day of the following month, as shown below. (This assumes that the data needed for the reports will be ready when the job is set to run.)
This cron job runs quarterly reports on the first day of the month after a quarter ends.
The following shows a job that runs one minute past every hour between 9:01 a.m. and 5:01 p.m.
Sometimes you want to run jobs at regular times during normal business hours.
I have encountered situations where I need to run a job every two, three, or four hours. That can be accomplished by dividing the hours by the desired interval, such as */3 for every three hours, or 6-18/3 to run every three hours between 6 a.m. and 6 p.m. Other intervals can be divided similarly; for example, the expression */15 in the minutes position means «run the job every 15 minutes.»
This cron job runs every five minutes during every hour between 8 a.m. and 5:58 p.m.
One thing to note: The division expressions must result in a remainder of zero for the job to run. That’s why, in this example, the job is set to run every five minutes (08:05, 08:10, 08:15, etc.) during even-numbered hours from 8 a.m. to 6 p.m., but not during any odd-numbered hours. For example, the job will not run at all from 9 p.m. to 9:59 a.m.
I am sure you can come up with many other possibilities based on these examples.