sys-whonix and clock skew
176 views
Skip to first unread message
William Waites
Jan 18, 2016, 1:21:18 PM1/18/16
to qubes...@googlegroups.com
For some time, I've been running whonix-gw in front of some of my
virtual machines (sometimes whonix-ws sometimes other). I find that
after suspending and reanimating the laptop tor dies. I've tracked
this down to the clock. On the whonix-gw it appears to stop and not
jump forward. Setting the time manually causes Tor open new circuits
and become happy again.
Does anything special need to be done to communicate the correct time
to the whonix-gw? I would have thought that it would find out from the
RTC, which appears to be the case with other virtual machines.
-w
virtual machines (sometimes whonix-ws sometimes other). I find that
after suspending and reanimating the laptop tor dies. I've tracked
this down to the clock. On the whonix-gw it appears to stop and not
jump forward. Setting the time manually causes Tor open new circuits
and become happy again.
Does anything special need to be done to communicate the correct time
to the whonix-gw? I would have thought that it would find out from the
RTC, which appears to be the case with other virtual machines.
-w
Wojtek Porczyk
Jan 19, 2016, 8:08:11 PM1/19/16
to William Waites, qubes...@googlegroups.com, adre...@riseup.net
sabotaged on purpose, because it would reveal user's time zone. You may
try to poke Whonix' custom time synchronisation mechanism, but I'm
unsure how it's exactly triggered.
Cc'ing Patrick, who will know better.
--
regards, _.-._
Wojtek Porczyk .-^' '^-.
Invisible Things Lab |'-.-^-.-'|
| | | |
I do not fear computers, | '-.-' |
I fear lack of them. '-._ : ,-'
-- Isaac Asimov `^-^-_>
Patrick Schleizer
Jan 20, 2016, 11:53:06 AM1/20/16
to William Waites, qubes...@googlegroups.com
Wojtek Porczyk:
https://www.whonix.org/wiki/Post_Install_Advice#Network_Time_Syncing
Also just now added here:
https://www.whonix.org/wiki/Known_Issues
> There's mechanism to sync clock from dom0 to VMs, but on Whonix it's
> sabotaged on purpose, because it would reveal user's time zone. You may
> try to poke Whonix' custom time synchronisation mechanism, but I'm
> unsure how it's exactly triggered.
Right. Making this a development discussion now...
sdwdate currently is run by a systemd service only.
When a VM in Qubes is resumed, will the VM just be resumed or will it be
notified by by some xen hook or /etc/qubes-rpc or similar? Such as
notification would be very useful. That hook could be used to restart
sdwdate, which could then fix smaller clock skews.
For fixing bigger clock skews I also have an idea. The sys-whonix /
anon-whonix VM would ask dom0 for an (approximate) time through qrexec.
And dom0 would reply with a slightly randomized time. That time could
then be used to get Tor, and sdwdate back on track.
A ton of information on time sync generally:
https://www.whonix.org/wiki/Dev/TimeSync
Cheers,
Patrick
> On Mon, Jan 18, 2016 at 06:14:09PM +0000, William Waites wrote:
>> For some time, I've been running whonix-gw in front of some of my
>> virtual machines (sometimes whonix-ws sometimes other). I find that
>> after suspending and reanimating the laptop tor dies. I've tracked
>> this down to the clock. On the whonix-gw it appears to stop and not
>> jump forward. Setting the time manually causes Tor open new circuits
>> and become happy again.
>>
>> Does anything special need to be done to communicate the correct time
>> to the whonix-gw? I would have thought that it would find out from the
>> RTC, which appears to be the case with other virtual machines.
It's a known issue. Documented here:
>> For some time, I've been running whonix-gw in front of some of my
>> virtual machines (sometimes whonix-ws sometimes other). I find that
>> after suspending and reanimating the laptop tor dies. I've tracked
>> this down to the clock. On the whonix-gw it appears to stop and not
>> jump forward. Setting the time manually causes Tor open new circuits
>> and become happy again.
>>
>> Does anything special need to be done to communicate the correct time
>> to the whonix-gw? I would have thought that it would find out from the
>> RTC, which appears to be the case with other virtual machines.
https://www.whonix.org/wiki/Post_Install_Advice#Network_Time_Syncing
Also just now added here:
https://www.whonix.org/wiki/Known_Issues
> There's mechanism to sync clock from dom0 to VMs, but on Whonix it's
> sabotaged on purpose, because it would reveal user's time zone. You may
> try to poke Whonix' custom time synchronisation mechanism, but I'm
> unsure how it's exactly triggered.
sdwdate currently is run by a systemd service only.
When a VM in Qubes is resumed, will the VM just be resumed or will it be
notified by by some xen hook or /etc/qubes-rpc or similar? Such as
notification would be very useful. That hook could be used to restart
sdwdate, which could then fix smaller clock skews.
For fixing bigger clock skews I also have an idea. The sys-whonix /
anon-whonix VM would ask dom0 for an (approximate) time through qrexec.
And dom0 would reply with a slightly randomized time. That time could
then be used to get Tor, and sdwdate back on track.
A ton of information on time sync generally:
https://www.whonix.org/wiki/Dev/TimeSync
Cheers,
Patrick
Marek Marczykowski-Górecki
Jan 20, 2016, 3:03:38 PM1/20/16
to Patrick Schleizer, William Waites, qubes...@googlegroups.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Currently the only think that'll happen (in non-NetVM) is
qubes.SetDateTime service call. Something disabled on purpose in Whonix,
and something we don't want to call in Whonix at all.
There is feature request for such script/service:
https://github.com/QubesOS/qubes-issues/issues/1663
> For fixing bigger clock skews I also have an idea. The sys-whonix /
> anon-whonix VM would ask dom0 for an (approximate) time through qrexec.
> And dom0 would reply with a slightly randomized time. That time could
> then be used to get Tor, and sdwdate back on track.
When that would happen? In response to #1663 service call? Or maybe on
some other basis?
> A ton of information on time sync generally:
> https://www.whonix.org/wiki/Dev/TimeSync
>
> Cheers,
> Patrick
>
- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQEcBAEBCAAGBQJWn+gRAAoJENuP0xzK19cstgUH/3J+LwudLDc35wTv5lhUNO4A
wDJrqmDUma/AVNy3+UFIbDW5PuVOOpWEWqOoo7rmkaaCXRKpKBZpDeaaj7h1fYty
m/y6S3Ca8QpKjXQgh8cnKpRqBis/5WZbgr4I09S7X1t29QgWTsXeOJNTaPbfJL22
MYfZL69DlfTT8UFCO0TOXwUK7Mf1Ehb57UjOCtIGVcoTW76jpcRIkaDt3ILe/rY1
Q4eJirnrWlAo7TG3rcGHkBNartVXkOMbhKoJCr+XbFG9XPvwB0xB8lwrSzlJRooz
enRNmjPNt1H94AoH2+5GcFMprnhYXAbnE4tnFQJcaPye+z3Gd4sNwXvk9bC4/Xk=
=48ww
-----END PGP SIGNATURE-----
Hash: SHA256
qubes.SetDateTime service call. Something disabled on purpose in Whonix,
and something we don't want to call in Whonix at all.
There is feature request for such script/service:
https://github.com/QubesOS/qubes-issues/issues/1663
> For fixing bigger clock skews I also have an idea. The sys-whonix /
> anon-whonix VM would ask dom0 for an (approximate) time through qrexec.
> And dom0 would reply with a slightly randomized time. That time could
> then be used to get Tor, and sdwdate back on track.
some other basis?
> A ton of information on time sync generally:
> https://www.whonix.org/wiki/Dev/TimeSync
>
> Cheers,
> Patrick
>
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQEcBAEBCAAGBQJWn+gRAAoJENuP0xzK19cstgUH/3J+LwudLDc35wTv5lhUNO4A
wDJrqmDUma/AVNy3+UFIbDW5PuVOOpWEWqOoo7rmkaaCXRKpKBZpDeaaj7h1fYty
m/y6S3Ca8QpKjXQgh8cnKpRqBis/5WZbgr4I09S7X1t29QgWTsXeOJNTaPbfJL22
MYfZL69DlfTT8UFCO0TOXwUK7Mf1Ehb57UjOCtIGVcoTW76jpcRIkaDt3ILe/rY1
Q4eJirnrWlAo7TG3rcGHkBNartVXkOMbhKoJCr+XbFG9XPvwB0xB8lwrSzlJRooz
enRNmjPNt1H94AoH2+5GcFMprnhYXAbnE4tnFQJcaPye+z3Gd4sNwXvk9bC4/Xk=
=48ww
-----END PGP SIGNATURE-----
Patrick Schleizer
Jan 20, 2016, 3:51:17 PM1/20/16
to Marek Marczykowski-Górecki, William Waites, qubes...@googlegroups.com
Marek Marczykowski-Górecki:
inside VM requests (approximate) time through qrexec -> dom0 would reply
Patrick
> On Wed, Jan 20, 2016 at 04:52:55PM +0000, Patrick Schleizer wrote:
>> Wojtek Porczyk:
>> Wojtek Porczyk:
>> When a VM in Qubes is resumed, will the VM just be resumed or will it be
>> notified by by some xen hook or /etc/qubes-rpc or similar? Such as
>> notification would be very useful. That hook could be used to restart
>> sdwdate, which could then fix smaller clock skews.
>
> Currently the only think that'll happen (in non-NetVM) is
> qubes.SetDateTime service call. Something disabled on purpose in Whonix,
> and something we don't want to call in Whonix at all.
>
> There is feature request for such script/service:
> https://github.com/QubesOS/qubes-issues/issues/1663
>
>> For fixing bigger clock skews I also have an idea. The sys-whonix /
>> anon-whonix VM would ask dom0 for an (approximate) time through qrexec.
>> And dom0 would reply with a slightly randomized time. That time could
>> then be used to get Tor, and sdwdate back on track.
>
> When that would happen? In response to #1663 service call?
VM gets notified that it was woke up after suspend (#1663) -> handler
>> notified by by some xen hook or /etc/qubes-rpc or similar? Such as
>> notification would be very useful. That hook could be used to restart
>> sdwdate, which could then fix smaller clock skews.
>
> Currently the only think that'll happen (in non-NetVM) is
> qubes.SetDateTime service call. Something disabled on purpose in Whonix,
> and something we don't want to call in Whonix at all.
>
> There is feature request for such script/service:
> https://github.com/QubesOS/qubes-issues/issues/1663
>
>> For fixing bigger clock skews I also have an idea. The sys-whonix /
>> anon-whonix VM would ask dom0 for an (approximate) time through qrexec.
>> And dom0 would reply with a slightly randomized time. That time could
>> then be used to get Tor, and sdwdate back on track.
>
> When that would happen? In response to #1663 service call?
inside VM requests (approximate) time through qrexec -> dom0 would reply
with a slightly randomized time.
Cheers,
Patrick
Frank
Jan 21, 2016, 5:03:21 AM1/21/16
to qubes...@googlegroups.com
>> On 20.01.2016, at 21:51, Patrick Schleizer patrick-ma...@whonix.org
>
> Regards, Frank
Forwarding to qubes-user mailing list, since I accidentally sent it to Patrick only.
Patrick Schleizer
Jan 21, 2016, 7:16:36 PM1/21/16
to qubes...@googlegroups.com
Frank:
That might also work, but I guess that would require the mgmt salt
management stack to set that setting for any Whonix based VM.
Cheers,
Patrick
management stack to set that setting for any Whonix based VM.
Cheers,
Patrick
William Waites
Jan 23, 2016, 5:40:20 AM1/23/16
to q5wrm...@snkmail.com, qubes...@googlegroups.com
My quick and dirty fix is this script that I run by hand. It fuzzes
the clock by +/- 15 seconds for each vm in my list... Seems to work
well enough to keep Tor happy as well as meet the Whonix desideratum
of not having perfectly synchronised clocks (which hadn't even
occurred to me as a potential problem before!).
Cheers,
-w
----
#!/usr/bin/python2
from qubes.qubes import QubesVmCollection
from time import gmtime, time, strftime
from random import randrange, seed
from sys import stdout
vms = ["sys-whonix", "anon-whonix", ...]
def fixtime(v):
fuztime = gmtime(time() + randrange(-15, 15, 1))
cmd = strftime("date -u %m%d%H%M%Y.%S", fuztime)
stdout.write("Time for %s:\t" % v.name)
v.run(cmd, user="root", passio=True)
def main():
qvm_collection = QubesVmCollection()
qvm_collection.lock_db_for_reading()
qvm_collection.load()
qvm_collection.unlock_db()
seed(time())
[fixtime(v) for v in qvm_collection.values()
if v.name in vms and v.is_running()]
main()
the clock by +/- 15 seconds for each vm in my list... Seems to work
well enough to keep Tor happy as well as meet the Whonix desideratum
of not having perfectly synchronised clocks (which hadn't even
occurred to me as a potential problem before!).
Cheers,
-w
----
#!/usr/bin/python2
from qubes.qubes import QubesVmCollection
from time import gmtime, time, strftime
from random import randrange, seed
from sys import stdout
vms = ["sys-whonix", "anon-whonix", ...]
def fixtime(v):
fuztime = gmtime(time() + randrange(-15, 15, 1))
cmd = strftime("date -u %m%d%H%M%Y.%S", fuztime)
stdout.write("Time for %s:\t" % v.name)
v.run(cmd, user="root", passio=True)
def main():
qvm_collection = QubesVmCollection()
qvm_collection.lock_db_for_reading()
qvm_collection.load()
qvm_collection.unlock_db()
seed(time())
[fixtime(v) for v in qvm_collection.values()
if v.name in vms and v.is_running()]
main()
donoban
Feb 1, 2016, 4:29:09 AM2/1/16
to qubes...@googlegroups.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I found today my anon-whonix VM at 25% of CPU usage. There was a ruby
process eating a core:
root 13768 100 18.5 772292 682612 ? Rl 22:14 6:41 ruby
/usr/lib/sdwdate/sclockadj --no-verbose --no-debug --no-first-wait
- --move-min 500000 --move-max 500000 --wait-min 1000000000 --wait-max
1000000000 --add 40028891820623
maybe it's related with this thread?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAEBAgAGBQJWryVTAAoJEBQTENjj7QilRxEP/RlalNJ/6NVZVqzFNYXbyYvC
qZdR6XfWJk1XZG3jt9Ps0RuhNDbP4JZeMgsotQSg360fL8Kxw9AJYmL5yTXi4IOB
4P5dTclfmMgez1gllaCROS/i8ECncYX+ghJQWvc2m4rfrwltLrbH3ed7VWSSX355
So4dRxZEyN4ESYodOvUo/VBDmOLSKsbs1HJHk0WtCPOQOlIo2ETP4JCa1C8EAcNR
ErFd8vSOqKrv/YrIVmtQ5ptfJw3fU4SYW9PuvOh8yEoQYMD2JKYFjYyZLV5WbUhg
NiaW47M4GBSkfvSfptlGZDL0cfs7MUBD8dGQ4WjK8XOdY1T/BYcQDuDvh+LYzsJE
aB8d8FQ3IG3txN9mqIWl0sOSKwbLD7rTj2ZBWjEEo5H5G+x2hgwSV5AQ76kx9W3K
yJRj3xU4ZTFwGwAy0V+CzJhj9+veWyrCS+ttm6z07xmQihXKBeu6XSrMQubI6Wez
eZP1fBexbm1QRLgRQkQacZlggd8myZh2A61PV34PIMaxdhFxJKW5oV5YnJu5k7x1
HV0D9GCtI88JNOVUVtgOps7f9yXmaNgI77sXZY8/JkSRfGodDwR5Y+ZTePdNTaDi
KptUhyyC34ItkiI3uU39F4NH5lBOf8UqiYaDAgnvv9VdJwqLiI24QaYuDCZRJTuj
d6zZOejfIenInyw512VM
=VuAT
-----END PGP SIGNATURE-----
Hash: SHA1
I found today my anon-whonix VM at 25% of CPU usage. There was a ruby
process eating a core:
root 13768 100 18.5 772292 682612 ? Rl 22:14 6:41 ruby
/usr/lib/sdwdate/sclockadj --no-verbose --no-debug --no-first-wait
- --move-min 500000 --move-max 500000 --wait-min 1000000000 --wait-max
1000000000 --add 40028891820623
maybe it's related with this thread?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAEBAgAGBQJWryVTAAoJEBQTENjj7QilRxEP/RlalNJ/6NVZVqzFNYXbyYvC
qZdR6XfWJk1XZG3jt9Ps0RuhNDbP4JZeMgsotQSg360fL8Kxw9AJYmL5yTXi4IOB
4P5dTclfmMgez1gllaCROS/i8ECncYX+ghJQWvc2m4rfrwltLrbH3ed7VWSSX355
So4dRxZEyN4ESYodOvUo/VBDmOLSKsbs1HJHk0WtCPOQOlIo2ETP4JCa1C8EAcNR
ErFd8vSOqKrv/YrIVmtQ5ptfJw3fU4SYW9PuvOh8yEoQYMD2JKYFjYyZLV5WbUhg
NiaW47M4GBSkfvSfptlGZDL0cfs7MUBD8dGQ4WjK8XOdY1T/BYcQDuDvh+LYzsJE
aB8d8FQ3IG3txN9mqIWl0sOSKwbLD7rTj2ZBWjEEo5H5G+x2hgwSV5AQ76kx9W3K
yJRj3xU4ZTFwGwAy0V+CzJhj9+veWyrCS+ttm6z07xmQihXKBeu6XSrMQubI6Wez
eZP1fBexbm1QRLgRQkQacZlggd8myZh2A61PV34PIMaxdhFxJKW5oV5YnJu5k7x1
HV0D9GCtI88JNOVUVtgOps7f9yXmaNgI77sXZY8/JkSRfGodDwR5Y+ZTePdNTaDi
KptUhyyC34ItkiI3uU39F4NH5lBOf8UqiYaDAgnvv9VdJwqLiI24QaYuDCZRJTuj
d6zZOejfIenInyw512VM
=VuAT
-----END PGP SIGNATURE-----
Patrick Schleizer
Feb 1, 2016, 8:56:34 AM2/1/16
to qubes...@googlegroups.com
donoban:
I wouldn't know why it would create so much CPU.
The ruby script is the following one. Anyone capable please have a look
what in that script could cause high cpu.
https://github.com/Whonix/sdwdate/blob/master/usr/lib/sdwdate/sclockadj
A replacement is planned nonetheless for unrelated reasons. However,
it's difficult and help is welcome.
https://github.com/Whonix/sdwdate/pull/4
Rationale behind sclockad[2] is preventing clock jumps [bad for all
sorts of things] and fingerprinting issues i.e. imitating ntp's time
adjustment frequency. More info:
https://www.whonix.org/wiki/Dev/TimeSync#Adjusting_time_slowly_using_adjtimex.2Fntp_adjtime
Cheers,
Patrick
> I found today my anon-whonix VM at 25% of CPU usage. There was a ruby
> process eating a core:
>
> root 13768 100 18.5 772292 682612 ? Rl 22:14 6:41 ruby
> /usr/lib/sdwdate/sclockadj --no-verbose --no-debug --no-first-wait
> process eating a core:
>
> root 13768 100 18.5 772292 682612 ? Rl 22:14 6:41 ruby
> /usr/lib/sdwdate/sclockadj --no-verbose --no-debug --no-first-wait
> --move-min 500000 --move-max 500000 --wait-min 1000000000 --wait-max
> 1000000000 --add 40028891820623
>
>
> maybe it's related with this thread?
>
Likely unrelated.
> 1000000000 --add 40028891820623
>
>
> maybe it's related with this thread?
>
I wouldn't know why it would create so much CPU.
The ruby script is the following one. Anyone capable please have a look
what in that script could cause high cpu.
https://github.com/Whonix/sdwdate/blob/master/usr/lib/sdwdate/sclockadj
A replacement is planned nonetheless for unrelated reasons. However,
it's difficult and help is welcome.
https://github.com/Whonix/sdwdate/pull/4
Rationale behind sclockad[2] is preventing clock jumps [bad for all
sorts of things] and fingerprinting issues i.e. imitating ntp's time
adjustment frequency. More info:
https://www.whonix.org/wiki/Dev/TimeSync#Adjusting_time_slowly_using_adjtimex.2Fntp_adjtime
Cheers,
Patrick
donoban
Feb 2, 2016, 3:26:07 AM2/2/16
to qubes...@googlegroups.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I was thinking on restarting anon-whonix VM before suspending my
Hash: SHA1
computer during night since it was not running sclockadj after I had
killed it. However, I had some things opened which I want to read so I
finally suspended my computer with annon-whonix running and sclockadj
stopped.
Today I waked up my computer and he came again:
root 27305 100 22.5 908916 689892 ? Rl 22:49 6:31 ruby
/usr/lib/sdwdate/sclockadj --no-verbose --no-debug --no-first-wait
- --move-min 500000 --move-max 500000 --wait-min 1000000000 --wait-max
1000000000 --add 33620163879229
He was using again 100% of CPU. Was it opened on wake up? Maybe is it
called by crond (I do no see it in crontab's) or another service/process
?
I would like to investigate and give more useful information but I am
pretty busy this days.
Regards.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAEBAgAGBQJWsGgWAAoJEBQTENjj7Qil1zAP/3zk+WeHybmIg2hQejPUZ+oY
Version: GnuPG v1
rJ9QYa1mVAwaUbGXul8GhLz/qtYxqR1uqBSu0/cvxdqDkBKRPwgzw3xXlwCnaGAh
84GXu9xVzPPDIYv0XQ6zxxa52JOPUOGoNBOi9b/omD/V5tJiD362Q8bx8jMmzPYZ
1ACXK/E8PSTBcHpTR403fv0i87cimWcHoA+voe7r+l0JhsJg67gUXpH6MtzS/F5j
IWXhRd9Db3Vpzdi/mCmHtv6A+Z/hNcO1eBHwR6ouHVhILl/ETd02Hn1gqGRrHmhA
1jY+cdKNnwhrGTbudPOC+sAxUKJkxC40QIdA4Kp8ZIpEItFV2jYYZW3WXzYCo/cn
3SrAEb3qCR36XV0klfXNa3HZ8puaDymDaOEqoJ7TMiuwPu1Zv0ab0adeT2Sj/ggx
39bgKXG66e6xk81WnEPd9vHeA/v85lEPyGE4pAKpjLY1rOnOAPrJMKrHzOGf8Uan
I7jddo7t/h3iNlCkdzR7Czqh74S3YFFSdDmB7PuyNxTYSZbSYcgLiDeukYxYbWVy
nO4zLQfMoR+AU/ZHpQV175tkkj/RQRISy9G6/7/eiWwBgFZljo6Wvd0kY9rDJT6D
NsxH3cFLU7bMaH8IrIZyEWq1mdw4T6c6Ie0DVvXmNq6jAHsk++n8OrnH10ia2fRc
62Yys84Zn6LNgcwp9NG0
=rnfb
-----END PGP SIGNATURE-----
Patrick Schleizer
Feb 3, 2016, 2:26:37 PM2/3/16
to donoban, qubes...@googlegroups.com
donoban:
https://groups.google.com/d/msg/qubes-users/QO4He5mZDzc/68iyt4-5BgAJ
It's not called by cron or otherwise. Called by sdwdate only. Help welcome.
Cheers,
Patrick
> I was thinking on restarting anon-whonix VM before suspending my
> computer during night since it was not running sclockadj after I had
> killed it. However, I had some things opened which I want to read so I
> finally suspended my computer with annon-whonix running and sclockadj
> stopped.
>
> Today I waked up my computer and he came again:
>
> root 27305 100 22.5 908916 689892 ? Rl 22:49 6:31 ruby
> /usr/lib/sdwdate/sclockadj --no-verbose --no-debug --no-first-wait
> computer during night since it was not running sclockadj after I had
> killed it. However, I had some things opened which I want to read so I
> finally suspended my computer with annon-whonix running and sclockadj
> stopped.
>
> Today I waked up my computer and he came again:
>
> root 27305 100 22.5 908916 689892 ? Rl 22:49 6:31 ruby
> /usr/lib/sdwdate/sclockadj --no-verbose --no-debug --no-first-wait
> --move-min 500000 --move-max 500000 --wait-min 1000000000 --wait-max
> 1000000000 --add 33620163879229
>
> He was using again 100% of CPU. Was it opened on wake up? Maybe is it
> called by crond (I do no see it in crontab's) or another service/process
> ?
>
> I would like to investigate and give more useful information but I am
> pretty busy this days.
>
> Regards.
>
You must have missed my previous message.
> 1000000000 --add 33620163879229
>
> He was using again 100% of CPU. Was it opened on wake up? Maybe is it
> called by crond (I do no see it in crontab's) or another service/process
> ?
>
> I would like to investigate and give more useful information but I am
> pretty busy this days.
>
> Regards.
>
https://groups.google.com/d/msg/qubes-users/QO4He5mZDzc/68iyt4-5BgAJ
It's not called by cron or otherwise. Called by sdwdate only. Help welcome.
Cheers,
Patrick
raah...@gmail.com
Mar 27, 2016, 8:27:13 PM3/27/16
to qubes-users, don...@riseup.net, patrick-ma...@whonix.org
I get the same issue, out nowhere sometimes i see ruby process eating a core on my machine till i kill it.
donoban
Apr 29, 2016, 3:43:16 AM4/29/16
to qubes...@googlegroups.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Thinking again on this problem...
Hash: SHA256
I don't know why but when I resume after a pretty long suspend (more
than 6-8hours) I always get tor working for some minutes. Then it
stops working and I have to manually set the clock.
Today I tested running timesync very fast after resume (while tor
seems working). It seems doing his job fine and I haven't notice the
100% cpu consuming process.
Could I easily force it to run timesync after wake up? Maybe some
better solutions are already done but I'm running last stable 3.1 dom0
version and I have to manual set the clock everyday.
Regards.
PD: Why could be tor working "fine" some minutes after wake up?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAEBCAAGBQJXIxCQAAoJEBQTENjj7QilLJ4QAIx+Wdj68xZQH/c+fE462JBa
Version: GnuPG v2
cbq+9KGobyenovZBvG6HfOD4AMjqONN9pitIqJxnvPmeOa2VOmDL/aDzXX11QcJM
CxpNrd2k8aRTjvQ9ndtXPdjFuUuwvqorI4tTkjNgds422FUTsB9e6cuPQQQye/sI
LVJZrtcalngZlCqOhTe4b1ZLk9R7bfrt6E/vhgEb1hmOu4Xs8Gbl6WA4bxnILGFN
go7DnBY5fgBWfkOTvfIP5HlwJv7O3iCv9ZrSMEgu5nuYV/b2Fn6v3b7pgLgnZmoZ
51XQ8iTfo+7ljcFZtRFWZCtDfle+iHK9MkmQv0QebUq2j6jg6rbX2KIN5cewewUK
H1Wr/90mnYUL/wpTcppd4lDtgDa1RZEk17TPapyRxDLZMbyiumYFhEGEbOB4YZhq
1HOPXoPvK+3GeNZB5rYo8xqgWXjzW2TLi+EbEfTIMcQRrxHZ5Xz8rmM/YSYkokix
LhMo5L7krip/nNm2xI3VETbIgVzaB4d+1SgoG5Vc5NqZ8JlSku/XUFtE/wQicp6d
0Mkly7aM477VjH9/hRGc+DR9P1DY1cJ8/KAgOGZwYTTeazM3FG977OooHfvyCjLK
FY3ERQoUO8/TZG8XRtq4RflyYDyQClJ+RWSGOdSs6bT9Qj1K3WTaDXLdmCXYQ/YP
pfeQvUgDEhJ2NFhryi1S
=G9qt
-----END PGP SIGNATURE-----
Reply all
Reply to author
Forward
0 new messages