在我的 debian wheezy 服务器上~的root用户目录中，经常出现以dead.letter（当前）以下内容命名的文件：
orion : Jul 25 10:17:31 : root : unable to resolve host orion
orion : Jul 26 02:17:18 : root : unable to resolve host orion
orion : Jul 26 21:17:19 : root : unable to resolve host orion
orion是服务器的主机名（通常可以解析，因为我有各种使用此主机名的服务/程序没有问题）。经过一番搜索，我发现有一个cron每小时运行的工作，即
17 * * * * root cd / && run-parts --report /etc/cron.hourly
这可以解释为什么这些错误只在整整 17 分钟后出现。唯一的脚本/etc/cron.hourly是fake-hwclock包含以下内容：
#!/bin/sh
#
# Simple cron script - save …我正在运行一个 cronjob，它检查服务器更新，一一安装它们，然后检查是否需要重新启动。如果需要重新启动，该脚本将启动reboot服务器。
硬件时钟在启动时使用，在使用系统时钟之前需要一分钟。
在切换到系统时钟之前，日志显示服务器晚了一个小时左右，当服务器从硬件切换到系统时钟时，日志跳转并提前了一个小时左右，这触发了 cron 守护进程，它注意到：服务器更新脚本的时间已过，请再次执行。
这会触发重新启动循环，因为该脚本仅每周执行一次。
执行hwclock --systohc会使系统时钟与硬件时钟同步，但不是永久的。重启后，时差又消失了。
我的问题是
如何使系统时钟与硬件时钟永久同步？
输出timedatectl status：
Local time: Tue 2018-08-28 12:05:37 CEST
Universal time: Tue 2018-08-28 10:05:37 UTC
RTC time: Tue 2018-08-28 10:05:37
Time zone: n/a (CEST, +0200)
NTP enabled: yes
NTP synchronized: yes
RTC in local TZ: yes
DST active: yes
Last DST change: DST began at
Sun 2018-03-25 01:59:59 CET
Sun 2018-03-25 03:00:00 CEST
Next DST change: DST ends (the clock jumps one hour backwards) …chonyd我遇到服务器日期问题。
我将硬件时钟日期从当前实际日期更改mar. nov. 27 15:57:12 CET 2018为mer. d\xc3\xa9c. 12 12:12:12 CET 2012使用以下命令：
hwclock --set --date="12/12/2012 12:12:12"\nhwclock -s\n我使用 启动 chronyd 服务systemctl start chronyd，并使用 检查状态systemctl status chronyd，以下输出显示该chronyd服务正在正确运行：
\xe2\x97\x8f chronyd.service - NTP client/server\n Loaded: loaded (/usr/lib/systemd/system/chronyd.service; enabled; vendor preset: enabled)\nActive: active (running) since mer. 2012-12-12 12:20:14 CET; 27min …RTC 会记住它的时间设置，linux 内核如何从 dev/rtc 获取这个时间并将其设置为 linux 时间。换句话说，在启动时 - 内核何时读取 rtc 并更新其 Linux 时间。
每次我启动我的笔记本电脑时，时钟都会差一个小时。我必须跑去ntpdate修理它。下次我重新启动笔记本电脑时，它将再次关闭。
我的时区设置正确。
我正在使用 Debian Wheezy
知道可能是什么原因吗？
我有几个容器（systemd-nspawn基于），我想知道我是应该设置时间（通过systemd-timesyncd）还是由主机维护？
在 Fedora 30 上，我目前在桌面环境中以 24 小时格式显示日期。我正在通过 chronyd 同步时间。但是在 CLI 上，时间显示Fri 22 Nov 2019 02:47:51 PM EST为所有用户。
我想将时间格式设置为使用 24 小时制。timedatectl设置和重新登录作为用户没有任何区别。
我有一台可以双启动 Kali Linux 和 Windows 的机器。我运行测试时的正确当地时间是 11:19 IST（印度标准时间），当然是 05:49 UTC。正如您从该问题的编辑历史记录中看到的，我最初是在几分钟后的 05:58 UTC 发布的。
该date命令得到的时区是正确的，但时间却完全错误。
$ date
Wednesday 19 August 2020 04:49:10 PM IST
正如问题评论中所述，这是 12 小时制，即 24 小时制的 16:49:10。该命令报告的当地时间比date实际时间早了 5 个半小时。
我桌面上 GUI 时钟的时间是 11:19，这是正确的。
大约一分钟前我运行了这个：
$ timedatectl
Local time: Wed 2020-08-19 16:47:50 IST
Universal time: Wed 2020-08-19 11:17:50 UTC
RTC time: Wed 2020-08-19 11:17:51
Time zone: Asia/Kolkata (IST, +0530)
System clock synchronized: no
NTP service: inactive
RTC in local TZ: no
正如您所看到的，时区是正确的，但当地时间却非常错误。有趣的是，如果那里的“世界时间”是 IST 而不是 UTC，那就是对的。 …
我有一个 Debian Buster 系统，其内核编译时没有使用CONFIG_RTC_SYSTOHC11 分钟内核模式，因为我不希望打开 11 分钟内核模式。然而，我想检查一下这个改变是否真的有效。
所以我检查了命令status输出中的字段adjtimex --print。该status字段是24577或0b110000000000001。
根据此处的手册页 - https://linux.die.net/man/8/adjtimex，似乎该64字段的位status是not set，根据此处： https: //access.redhat.com/solutions/ 55432表示已11-minute mode打开。
CONFIG_RTC_SYSTOHC这与我使用as编译内核时的预期相矛盾not set。如何可靠地检查 11 分钟模式是否确实关闭，或者我是否adjtimex错误地解释了输出？
在多个关于设置 NFS 的教程中，也有关于设置 NTP 的建议，以避免不同系统的时钟之间的差异。