3

I see an anonymous process changing the time of my systemtime to UTC every 80 sec. Using the journalctl -f command I only see a message that says 'systemd[1]: time has been changed' but it doesn't identify which process is doing that.

I know that any one who changes system time has to edit /etc/localtime file. Is there anyway I can find that process and let it leaves traces, so that I can identify what process it is ?

user1851006
  • 141
  • 2
  • 3

2 Answers2

2

I think you want to take a look at auditd. The following document is from Redhat, but is also applicable to CentOS 7:

How to monitor permission, ownership or any other change to a particular directory or file

guzzijason
  • 1,410
  • 8
  • 18
1

/etc/localtime determines the default timezone of the system. It is not necessary to change this file when adjusting the system time, unless you're also changing the system default timezone at the same time.

The message systemd[1]: time has been changed means something is adjusting the system clock. It could be ntpd, systemd-timesyncd or any other NTP client.

Note that the date command will show a timezone specifier along with the date and time. If the timezone specifier changes, something is manipulating the timezone settings: if it does not change when system time is changed, the system clock is being adjusted and the timezone settings are left alone.

If a NTP time synchronization causes the regular date command output to jump to UTC, then your timezone is incorrectly set. You can either use a timedatectl set-timezone command to set your timezone, or just copy the appropriate time zone specification file from /usr/share/zoneinfo/ to /etc/localtime. To avoid confusing the configuration tools, you should also change the value in /etc/sysconfig/clock to match the new default system timezone - but remember that /etc/localtime is the primary thing that actually determines the default system timezone. /etc/sysconfig/clock just provides an easy way for the configuration tools to find out what the current setting is.


Some background information:

The system clock of any Unix-style system is supposed to always run in UTC internally. All timestamp values should be converted to UTC on input and back to the user's preferred timezone on output. The NTP time synchronization also fundamentally uses UTC only, so it fits in well with this Unix standard practice.

/etc/localtime and/or the TZ environment variable only determine the conversions used. This way, each user, or even each separate program could use a different timezone (by setting the TZ environment variable whenever a non-default timezone is needed), and the system could still have an unified concept of time.

This scheme was developed back when computers were rare, large and expensive things, and users might be using text-based modem connections to access a single central computer from multiple timezones.

Because Linux must sometimes co-exist in a dual-boot system with Windows, Linux has a separate concept of a hardware clock. That is the small, usually battery-operated device that maintains the system time when the system is powered off. The system clock, on the other hand, is based on kernel's timekeeping algorithms (and possibly the processor's timestamp counter registers, if available and free of known hardware bugs).

The hardware clock can be set to either local or UTC time. The third line in /etc/adjtime file determines whether a conversion from local to UTC time is applied when copying the hardware clock time to the system clock when Linux is starting up, or if the hardware clock is assumed to use the UTC time directly. The latter option is much more robust in the face of timezone and Daylight Saving Time changes, but historically Windows has assumed that the system clock uses local time, and so Linux needs to be able to conform to that.

telcoM
  • 4,448
  • 15
  • 25