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).
Sep 18 2018
Aug 7 2018
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.
Aug 6 2018
/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.
Aug 5 2018
Jul 27 2018
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).
Jul 25 2018
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.
Oct 31 2017
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.
Jul 23 2017
Unless someone else will be taking this one...
Jul 7 2017
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.
Jun 29 2017
@marmarek this is probably due to Qubes current DispVM savefile implementation? It should fix itself in Qubes R4.0 since DispVM implementation changed there?
Jun 22 2017
For now, I remain positive this can and should be sorted out for Whonix 14.
Jun 20 2017
Removing Whonix 14 tag. It's not necessary to block 14.
Jun 17 2017
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.
Jun 16 2017
is it working for you?
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:
- 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
Jun 15 2017
Jun 14 2017
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.
Jun 8 2017
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?
Using adjtime would be a simple matter (of programming), but only has microsecond precision.
Jun 7 2017
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.
Jun 6 2017
Ported (in sdwdate master) and currently testing.
It would avoid trashing logs with Time has been changed every single second, and possibly other side effects.
Jun 5 2017
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.
Jun 3 2017
@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.
Mar 17 2017
Yes, sclockadj runs as root. Usually sclockadj is functional.
Mar 16 2017
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
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...
Feb 4 2017
Jan 12 2017
Mar 15 2016
Jun 21 2015
Feb 9 2015
Jan 16 2015
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.
Jan 15 2015
Any idea @JasonJAyalaP?
Jan 12 2015
Dec 16 2014
Added more debugging info:
After some searching, I conclude, it could be related to permissions:
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.