https://www.kicksecure.com/wiki/Dev/sdwdate#chrony_as_a_replacement_for_sclockadj

Actually, the "apt-daily.timer: Adding 1h 17min 24.927437s random time" message have real impact, not only noise. Each time sdwdate change time, systemd adds a random delay to those timers. which means the timer will never expire (unless that random delay will happen to be very close to 0 - i.e. below the time until sdwdate change the time, which looks to be 1s).

In theory, we could make sdwdate provide a local (default) (or optional opt-in server) NTP compatible time provider. Could be useful anyhow. -> sdwdate-server No idea how hard that would be.

And then configure NTP to connect only to that local NTP server.

/usr/sbin/ntpdate as far as I know doesn't accept a command line command to take an offset (or anything). It connects to remote servers in its default design.

Yes, not readily accessible from command line.

The easy way: calculating the offset between local time and the onion average in timesync then using ntpdate's slew option if the offset is less than 0.5s. Otherwise you tell it to step up the time immediately so that you are accurately mimicking the default behavior. However you can force slewing all the time with -B. This way you won't need to touch kernel syscalls as ntpdate should be able to do the operation for you.

From what I understand, this code path is only relevant when timesyncd is talking directly with NTP servers and reacting to replies about deltas between local and remote times. There is no way you can call that function from the command line when using timedatectl standalone AFAICT.

In T815#16509, @HulaHoop wrote:

It doesn't seem that timedatectl supports gradual time adjustment.

Since we are interested in ntpd's default behavior (for blending in purposes) it turns out that it performs instant clock jumps once the delta difference is excessively large otherwise its slewing algorithm would take forever to adjust the time.

It doesn't seem that timedatectl supports gradual time adjustment. Our next best option is ntpd which can do so but cannot coexist with timedatectl - we can only run either but not both. According to popcon, ntpd is the mos widely used time daemon so its the natural choice.

Currently time is set using gnu date (clock jump) (initial run after current boot) or sclockadj (consecutive run) (slow clock adjustment).

the time could be set with timedatectl by feeding it the time with this command:

Stretch+ uses systemd-timesyncd by default therefore its the most popular.

This is sorted in a later version of systemd.

sclockadj3 is done -> T686.

Qubes-Whonix DispVMs won't get any more development attention in Qubes
R3.2 because so much has changed. Please look into Qubes R4.

I didn't notice this bug earlier but caught a reference in one of the Qubes mailing list discussions. For what it's worth, I got this to function under Qubes 3.2 by deleting the sdwdate systemd unit files. It has been a while but I think I did that in the whonix-ws template. The dispvm appears to call bootclockrandomization on every start so time correlation is avoided and I no longer encounter times off by 2+ weeks.

Unless someone else will be taking this one...

Yes to both of you:

• should just work on Qubes 4.0 (savefiles are not used there anymore)
• calling qubes.GetRandomizedTime as post-suspend action would fix that too

This does not seem to happen every time, strangely enough. It seems sdwdate should call qubes.GetRandomizedTime as a post-suspend action if I read this correctly. So I guess under some circumstances that step does not run.

@marmarek this is probably due to Qubes current DispVM savefile implementation? It should fix itself in Qubes R4.0 since DispVM implementation changed there?

For now, I remain positive this can and should be sorted out for Whonix 14.

Removing Whonix 14 tag. It's not necessary to block 14.

In T691#13739, @JasonJAyalaP wrote:

http://www.ntp.org/ntpfaq/NTP-s-algo.htm#Q-CLOCK-DISCIPLINE

JasonJAyalaP (Jason J. Ayala P.):

JasonJAyalaP added a comment.

@Patrick 
is it working for you?

When ntp needs to adjust more than 128ms, it uses settimeofday to make one big jump.

@Patrick
is it working for you?

s.sh (ssh):

s.sh added a comment.

Is there a way to use functions like clock_settime without
reporting to the log

There are generally three ways:

1. Hook into the related library call and prevent the syscall

function from being called. 2. Immediately after writing to system
logs following a call to clock_settime() make the appended logs
removed. 3. During the time of calling clock_settime(), disable the
syslog at system level, after returning from the aforementioned
function re-enable logging.

Is there a way to use functions like clock_settime without reporting to the log

Please create a new ticket for porting to some better C function.

adjtimex, as far as I can tell, is for tuning the clock to stay accurate. It's not directly for setting a new time. I assume it's used by ntp to speed up and slow down the clock, with more code that checks on it and stops it when it reaches the right time. Reimplementing this is beyond my skill.

OK. It might strain my limited C knowledge, but I'll give it shot.

Looks like at least NTP and chrony use ntp_adjtime/adjtimex

Where is adjtime being used in existing time sync applications? NTP?
chrony? systemd-timesyncd?

Using adjtime would be a simple matter (of programming), but only has microsecond precision.

A popular existing linux tool.

Do we need precise control? The only requirement (other than working) is that it imitate an existing linux tool.

adjtimex/ntp_adjtime looks quite complex, but also allow precise control on how time should be adjusted. From those two, according to manual page ntp_adjtime is preferred.

Ported (in sdwdate master) and currently testing.

In T650#13569, @marmarek wrote:

It would avoid trashing logs with Time has been changed every single second, and possibly other side effects.

I've left you some minor comments here: https://github.com/JasonJAyalaP/sclockadj/commit/e9bf84e3a400f7a8ef01e5f00dcefc013d0a9efe

What about using adjtime() syscall instead of all this? It would avoid trashing logs with Time has been changed every single second, and possibly other side effects.

Done.

Could you please commit sclockadj.c to the root folder of https://github.com/Whonix/sdwdate so we can account your authorship in the git history? @JasonJAyalaP

@marmarek Would you be willing to review the C? It's under 75 total lines.

I've rewritten the whole thing in C. It was a simple matter since we no longer need the random interval algorithm. Patrick prefers that it imitates ntpd instead of trying to hide.

Yes, sclockadj runs as root. Usually sclockadj is functional.

the clock_gettime and clock_settime functions are passing zero as their first parameters and that means CLOCK_REALTIME. Firstly the process needs root privilege to touch real time clock, secondly you need to somehow run it by strace like:

TZ is unset since it's started as a systemd unit file.

The C code itself doesn't have any CPU intensive instruction, if the problem is really what is written as inline C, I suspect the issue is either with

clock_gettime(0, &tps)

or

Can't find what debian package ship debug symbols, there is no -dbg package there: https://packages.debian.org/source/stretch/ruby2.3

Ah, it's ruby... So, python-dbg is irrelevant, but trying gdb may still be a good idea.

Thanks for having a look!

I don't see any loop there and only very simple function calls, so I don't see how that would trigger such bug...

Ok. Closed for now. Should be fixed. Didn't run into this issue for a while now. And if it happens again, there will be helpful debug output. In case I notice again, I'll reopen.

It looks like ruby_inline thinks there's pre-compiled code in the inline dir, tries to load it, but fails. I don't know if that's because there isn't the compiled code (and ruby inline should have compiled it) or some other reason. That load error is too generic to be sure.

Any idea @JasonJAyalaP?

Added more debugging info:
https://github.com/Whonix/sdwdate/commit/2b768717083fc9e7b1ff12d9e6ae58e975e5a1c6

Attempt to fix:
https://github.com/Whonix/sdwdate/commit/ddab4502cfa5959279c735f0f283401cd67d9be6

After some searching, I conclude, it could be related to permissions:
https://github.com/Whonix/sdwdate/blob/master/debian/sdwdate.postinst#L28
Would perhaps be better if owned by root.

Probably unrelated: sclockadj stuck at 100% CPU.

By the way, this also happed before changing INLINEDIR once.