[HOME] [DOWNLOAD] [DOCS] [NEWS] [SUPPORT] [TIPS] [ISSUES] [DONATE]

Skype problems: time, clock jumps, and constant disconnections

Support
#1

Hello,

I’m using skype (chat only) within Whonix and I have two big problems:

  1. When someone speaks to me on skype, it happens that its message is not sent at the right time, therefore I have to browse the day history and it makes no sense. Some sentences are popping out from nowhere in the past conversation. It becomes senseless and hard to understand.
    And when I open up skype for the first time, if someone sent me a message offline, it’s most of the time not showing at the right time neither.

Solution: How can I stop using these changing clocks all the time? I tried to modify setting on the date but it seems to be set deeper inside the OS. I’m not using Whonix because I fear for my life, so don’t worry :slight_smile:

  1. Many times I get disconnected from skype without any reason and then it’s very hard to reconnect.

Thanks

#2

Shouldn’t happen in recent Whonix versions. What Whonix version are you using? Does whonixcheck say there everything is up to date?

#3

in virtualbox it says whonix workstation 10.0.0.5.5
Yes I didn’t update for the last 5 days but I don’t think it’s related at all.
I will update though and the disconnection are not occuring today but some days it’s all the time.

But the clock problem is very annoying.

Also, is it a bad habit to put the host OS in “sleep mode” while whonix is active?

PS: why there is no auto update?

#4

Yes, updates aren’t related. 10.0.0.5.5 is recent enough. Should not have this issue.

Can you check…

Is activity by sdwdate related to clock jumps?

Also, is it a bad habit to put the host OS in "sleep mode" while whonix is active?
That's worth a separate topic.
PS: why there is no auto update?
Technically difficult: https://www.whonix.org/wiki/Dev/Automatic_Updates
#5

I don’t get what it’s shown after this command:

2382: sdwdate_subshell_read: sclockadj reports: /var/cache/sdwdate/sclockadj root root 700
2382: sdwdate_subshell_read: sclockadj reports: /var/cache/sdwdate/sclockadj/.ruby_inline root root 700
2382: sdwdate_subshell_read: sclockadj reports: /var/cache/sdwdate/sclockadj/.ruby_inline/ruby-1.9.1 root root 700
2382: sdwdate_subshell_read: sclockadj reports: /var/cache/sdwdate/sclockadj/.ruby_inline/ruby-1.9.1/Inline_Cinline_45aeaf467303ff06d9c25b91daa74e32.so root root 755
2382: sdwdate_subshell_read: sclockadj reports: /var/cache/sdwdate/sclockadj/.ruby_inline/ruby-1.9.1/Inline_Cinline_45aeaf467303ff06d9c25b91daa74e32.c root root 644
2382: sdwdate_subshell_read: sclockadj reports: + true '$?: 0’
2382: sdwdate_subshell_read: sclockadj reports: sdwdate_subshell_time_start: Time before running sclockadj: 1434825348.060917378 [Sat Jun 20 19:35:48 IST 2015]
2382: sdwdate_subshell_read: sclockadj reports: sdwdate_subshell_wait: Waiting for pid to finish SDWDATE_SCLOCKADJ_COMMAND_PID: 20056
2382: dispatching DISPATCH_POST_SUCCESS done.
2382: Sleeping for 142 minutes. (RANDOMIZE: 1)

#6

Nothing. Sorry, I forgot to mention… You’re supposed to leave that running. Feel free to minimize it. Just keep it running. And when you run into issues, clock jumps, compare with that log.

#7

ok it’s already running and I don’t think it changed at all for the moment

#8

Expected.

2382: Sleeping for 142 minutes. (RANDOMIZE: 1)
So up to ~ 142 minutes nothing will happen. (The log does not have time stamps, so you don't know how much time already passed. That's why it's 'up to ~'.)

Just keep it open and see if you at some point can guess a correlation. I.e. once you experience issues, compare with that log.

Instructions for deactivating sdwdate are here:

But I recommend to play it safe. I.e. getting to the bottom of it. There could be something else changing your clock. And we ought to find out what could that be.

#9

In fact, it happens everytime I put the host OS on sleep mode and come back on skype.

here is one of the log I saw after doing this but I don’t understand anything

2410: sdwdate_subshell_read: sclockadj reports: /var/cache/sdwdate/sclockadj root root 700
2410: sdwdate_subshell_read: sclockadj reports: /var/cache/sdwdate/sclockadj/.ruby_inline root root 700
2410: sdwdate_subshell_read: sclockadj reports: /var/cache/sdwdate/sclockadj/.ruby_inline/ruby-1.9.1 root root 700
2410: sdwdate_subshell_read: sclockadj reports: /var/cache/sdwdate/sclockadj/.ruby_inline/ruby-1.9.1/Inline_Cinline_45aeaf467303ff06d9c25b91daa74e32.so root root 755
2410: sdwdate_subshell_read: sclockadj reports: /var/cache/sdwdate/sclockadj/.ruby_inline/ruby-1.9.1/Inline_Cinline_45aeaf467303ff06d9c25b91daa74e32.c root root 644
2410: sdwdate_subshell_read: sclockadj reports: + true '$?: 0’
2410: sdwdate_subshell_read: sclockadj reports: sdwdate_subshell_time_start: Time before running sclockadj: 1435001436.581467654 [Mon Jun 22 20:30:36 IST 2015]
2410: sdwdate_subshell_read: sclockadj reports: sdwdate_subshell_wait: Waiting for pid to finish SDWDATE_SCLOCKADJ_COMMAND_PID: 14078
2410: dispatching DISPATCH_POST_SUCCESS done.
2410: Sleeping for 167 minutes. (RANDOMIZE: 1)
2410: sdwdate_subshell_read: sclockadj reports: sdwdate_subshell_wait: SDWDATE_SCLOCKADJ_COMMAND_PID: 14078 | SDWDATE_SCLOCKADJ_COMMAND_EXIT_CODE: 0
2410: sdwdate_subshell_read: sclockadj reports: sdwdate_subshell_time_end: was running for 3026 s [~ 50.43 min] [~ 0.84 h].
2410: sdwdate_subshell_read: sclockadj reports: sdwdate_subshell_time_end: Time after running sclockadj: 1435004462.275308177 [Mon Jun 22 21:21:02 IST 2015]
2410: sdwdate_subshell_read: sclockadj reports: exit code: 0
2410: sdwdate_subshell_read: end

And this one is another from yesterday but I don’t know if it’s useful :

2378: sdwdate_subshell_read: sclockadj reports: /var/cache/sdwdate/sclockadj root root 700
2378: sdwdate_subshell_read: sclockadj reports: /var/cache/sdwdate/sclockadj/.ruby_inline root root 700
2378: sdwdate_subshell_read: sclockadj reports: /var/cache/sdwdate/sclockadj/.ruby_inline/ruby-1.9.1 root root 700
2378: sdwdate_subshell_read: sclockadj reports: /var/cache/sdwdate/sclockadj/.ruby_inline/ruby-1.9.1/Inline_Cinline_45aeaf467303ff06d9c25b91daa74e32.so root root 755
2378: sdwdate_subshell_read: sclockadj reports: /var/cache/sdwdate/sclockadj/.ruby_inline/ruby-1.9.1/Inline_Cinline_45aeaf467303ff06d9c25b91daa74e32.c root root 644
2378: sdwdate_subshell_read: sclockadj reports: + true '$?: 0’
2378: sdwdate_subshell_read: sclockadj reports: sdwdate_subshell_time_start: Time before running sclockadj: 1434910248.867010630 [Sun Jun 21 19:10:48 IST 2015]
2378: sdwdate_subshell_read: sclockadj reports: sdwdate_subshell_wait: Waiting for pid to finish SDWDATE_SCLOCKADJ_COMMAND_PID: 22989
2378: dispatching DISPATCH_POST_SUCCESS done.
2378: Sleeping for 156 minutes. (RANDOMIZE: 1)
2378: sdwdate_subshell_read: sclockadj reports: sdwdate_subshell_wait: SDWDATE_SCLOCKADJ_COMMAND_PID: 22989 | SDWDATE_SCLOCKADJ_COMMAND_EXIT_CODE: 0
2378: sdwdate_subshell_read: sclockadj reports: sdwdate_subshell_time_end: was running for 3018 s [~ 50.30 min] [~ 0.83 h].
2378: sdwdate_subshell_read: sclockadj reports: sdwdate_subshell_time_end: Time after running sclockadj: 1434913266.921978101 [Sun Jun 21 20:01:06 IST 2015]
2378: sdwdate_subshell_read: sclockadj reports: exit code: 0
2378: sdwdate_subshell_read: end
2378: Running sdwdate… pid: 2378 | LD_PRELOAD:
2378: sdwdate_preparation: who_ami is set to user.
2378: dispatching DISPATCH_PRE (SDW_MODE: daemon): /usr/lib/timesync/timesync_pre --autostart --identifier “timesync” --progressbaridx “$ID” --mode “$SDW_MODE” --whoami "$who_ami"
2378: dispatching DISPATCH_PRE done.
2378: dispatching DISPATCH_PREREQUISITE (SDW_MODE: daemon) (LD_PRELOAD: ): /usr/lib/anon-shared-helper-scripts/te_pe_tb_check
2378: DISPATCH_PREREQUISITE exited 0, continuing…
2378: SDWDATE_CURRENT_POOL: SDWDATE_POOL_ONE | array_length: 14 | allowed_member_failures: 5 | temp: 4.76 | array_length_remember: 0
2378: dispatching {SDWDATE_TIME_TOOL_DISPATCH_PRE[SDWDATE_POOL_ONE]} (SDW_MODE: daemon): /usr/lib/timesync/timesync_progress --identifier “timesync” --progressbaridx “$ID” --mode “$SDW_MODE” --whoami “$who_ami” --progressx 15
2378: dispatching {SDWDATE_TIME_TOOL_DISPATCH_PRE[SDWDATE_POOL_ONE]} done.
2378: get : pubdrop4dw6rk3aq.onion:80 | local time: Sun Jun 21 21:46:50 IST 2015 | link_comment_part: ProPublica https://securedrop.propublica.org pubdrop4dw6rk3aq.onion
2378: result: pubdrop4dw6rk3aq.onion:80 | local time: Sun Jun 21 21:47:17 IST 2015 | status: failed | took: 27s | download_tool_exit_code: 2 | stdout: | stderr: connect error: URL “pubdrop4dw6rk3aq.onion” not found.
2378: SDWDATE_CURRENT_POOL: SDWDATE_POOL_ONE | array_length: 14 | allowed_member_failures: 5 | temp: 4.76 | array_length_remember: 1
2378: dispatching {SDWDATE_TIME_TOOL_DISPATCH_PRE[SDWDATE_POOL_ONE]} (SDW_MODE: daemon): /usr/lib/timesync/timesync_progress --identifier “timesync” --progressbaridx “$ID” --mode “$SDW_MODE” --whoami “$who_ami” --progressx 15
2378: dispatching {SDWDATE_TIME_TOOL_DISPATCH_PRE[SDWDATE_POOL_ONE]} done.
2378: get : strngbxhwyuu37a3.onion:80 | local time: Sun Jun 21 21:47:17 IST 2015 | link_comment_part: The New Yorker https://projects.newyorker.com/strongboxstrngbxhwyuu37a3.onion
2378: result: strngbxhwyuu37a3.onion:80 | local time: Sun Jun 21 21:47:26 IST 2015 | status: success | took: 9s | diff: 5737 second(s)
2378: dispatching {SDWDATE_TIME_TOOL_DISPATCH_POST[SDWDATE_POOL_ONE]} (SDW_MODE: daemon): /usr/lib/timesync/timesync_progress --identifier “timesync” --progressbaridx “$ID” --mode “$SDW_MODE” --whoami “$who_ami” --progressx 30
2378: dispatching {SDWDATE_TIME_TOOL_DISPATCH_POST[SDWDATE_POOL_ONE]} done.
2378: SDWDATE_CURRENT_POOL: SDWDATE_POOL_TWO | array_length: 17 | allowed_member_failures: 6 | temp: 5.78 | array_length_remember: 0
2378: dispatching {SDWDATE_TIME_TOOL_DISPATCH_PRE[SDWDATE_POOL_TWO]} (SDW_MODE: daemon): /usr/lib/timesync/timesync_progress --identifier “timesync” --progressbaridx “$ID” --mode “$SDW_MODE” --whoami “$who_ami” --progressx 45
2378: dispatching {SDWDATE_TIME_TOOL_DISPATCH_PRE[SDWDATE_POOL_TWO]} done.
2378: get : abkjckdgoabr7bmm.onion:80 | local time: Sun Jun 21 21:47:27 IST 2015 | link_comment_part: MediaDirect [43] 2014-May-11 Transparency Activism abkjckdgoabr7bmm.onion https://abkjckdgoabr7bmm.tor2web.org Australia
2378: result: abkjckdgoabr7bmm.onion:80 | local time: Sun Jun 21 21:48:03 IST 2015 | status: success | took: 37s | diff: 5737 second(s)
2378: dispatching {SDWDATE_TIME_TOOL_DISPATCH_POST[SDWDATE_POOL_TWO]} (SDW_MODE: daemon): /usr/lib/timesync/timesync_progress --identifier “timesync” --progressbaridx “$ID” --mode “$SDW_MODE” --whoami “$who_ami” --progressx 60
2378: dispatching {SDWDATE_TIME_TOOL_DISPATCH_POST[SDWDATE_POOL_TWO]} done.
2378: SDWDATE_CURRENT_POOL: SDWDATE_POOL_THREE | array_length: 11 | allowed_member_failures: 4 | temp: 3.74 | array_length_remember: 0
2378: dispatching {SDWDATE_TIME_TOOL_DISPATCH_PRE[SDWDATE_POOL_THREE]} (SDW_MODE: daemon): /usr/lib/timesync/timesync_progress --identifier “timesync” --progressbaridx “$ID” --mode “$SDW_MODE” --whoami “$who_ami” --progressx 65
2378: dispatching {SDWDATE_TIME_TOOL_DISPATCH_PRE[SDWDATE_POOL_THREE]} done.
2378: get : uj3wazyk5u4hnvtk.onion:80 | local time: Sun Jun 21 21:48:04 IST 2015 | link_comment_part: https://thepiratebay.se/blog/238
2378: result: uj3wazyk5u4hnvtk.onion:80 | local time: Sun Jun 21 21:48:13 IST 2015 | status: success | took: 9s | diff: 5738 second(s)
2378: dispatching {SDWDATE_TIME_TOOL_DISPATCH_POST[SDWDATE_POOL_THREE]} (SDW_MODE: daemon): /usr/lib/timesync/timesync_progress --identifier “timesync” --progressbaridx “$ID” --mode “$SDW_MODE” --whoami “$who_ami” --progressx 80
2378: dispatching {SDWDATE_TIME_TOOL_DISPATCH_POST[SDWDATE_POOL_THREE]} done.
2378: Results summary: one: 5737 | two: 5737 | three: 5738 | second(s)
2378: Min: 5737 | Max: 5738 | Median diff: 5737 second(s) [5737000000000 nanosecond(s)]
2378: local unixtime : 1434919693 | local time : Sun Jun 21 21:48:13 IST 2015
2378: remote unixtime: 1434925430 | remote time: Sun Jun 21 23:23:50 IST 2015
2378: sdwdate_terminate_sclockadj: subshell for sclockadj with pid 22970 no longer running. Exit code: 0
2378: sdwdate_terminate_sclockadj: subshell for sclockadj with pid 22970 exited with expected zero exit code: 0
2378: Made up random extra: +0.652694963 second[s] [+652694963 nanosecond(s)].
2378: require time change: +5737.65 second(s) [5737652694963 nanosecond(s)]
2378: Launching into background: sudo INLINEDIR=/var/cache/sdwdate/sclockadj /usr/lib/sdwdate/sclockadj --no-verbose --no-debug --no-first-wait --move-min 500000 --move-max 500000 --wait-min 1000000000 --wait-max 1000000000 --add 5737652694963
2378: Started subshell for sclockadj with pid: 32742
2378: sdwdate_subshell_read: start
2378: dispatching DISPATCH_POST_SUCCESS (SDW_MODE: daemon): /usr/lib/timesync/timesync_post_success --autostart --identifier “timesync” --progressbaridx “$ID” --mode “$SDW_MODE” --whoami "$who_ami"
2378: sdwdate_subshell_read: sclockadj reports: + find /var/cache/sdwdate -printf '%p %u %g %m\n’
2378: sdwdate_subshell_read: sclockadj reports: /var/cache/sdwdate root root 755
2378: sdwdate_subshell_read: sclockadj reports: /var/cache/sdwdate/sclockadj root root 700
2378: sdwdate_subshell_read: sclockadj reports: /var/cache/sdwdate/sclockadj/.ruby_inline root root 700
2378: sdwdate_subshell_read: sclockadj reports: /var/cache/sdwdate/sclockadj/.ruby_inline/ruby-1.9.1 root root 700
2378: sdwdate_subshell_read: sclockadj reports: /var/cache/sdwdate/sclockadj/.ruby_inline/ruby-1.9.1/Inline_Cinline_45aeaf467303ff06d9c25b91daa74e32.so root root 755
2378: sdwdate_subshell_read: sclockadj reports: /var/cache/sdwdate/sclockadj/.ruby_inline/ruby-1.9.1/Inline_Cinline_45aeaf467303ff06d9c25b91daa74e32.c root root 644
2378: sdwdate_subshell_read: sclockadj reports: + true '$?: 0’
2378: sdwdate_subshell_read: sclockadj reports: sdwdate_subshell_time_start: Time before running sclockadj: 1434919693.436926953 [Sun Jun 21 21:48:13 IST 2015]
2378: sdwdate_subshell_read: sclockadj reports: sdwdate_subshell_wait: Waiting for pid to finish SDWDATE_SCLOCKADJ_COMMAND_PID: 32762
2378: dispatching DISPATCH_POST_SUCCESS done.
2378: Sleeping for 153 minutes. (RANDOMIZE: 1)

:’( I’m clueless

#10

So it’s not an sdwdate issue, most likely.

Sleep mode and time in VMs don’t play well together. After waking up the VMs, they don’t get any signal to fetch a current time.

Workaround:
a) don’t use sleep mode, or b
b) manually correct time after waking up in VMs; then restart sdwdate

#11

I’ll tell you if I notice it happening without that sleep mode stuff though.

But if i correct manually the time, skype won’t change the delivery date of the messages :smiley:

Restart sdwdate, do you have a command for this?

PS: ty for whonix and the help, i’ll ask more questions in another thread

#12

Ok.

Restart sdwdate, do you have a command for this?
Start Menu -> Applications -> System -> Secure Network Time Synchronization

Or in terminal.

Btw, sleep mode is mentioned here:

#13

Btw, Skype:

#14

Did it ever happen again without sleep mode involved?

[Imprint] [Privacy Policy] [Cookie Policy] [Terms of Use] [E-Sign Consent] [DMCA] [Investors] [Priority Support] [Professional Support]