This is the same kind of problem I had under Xen in the beginning. The
fix is to figure out what vmware gives you in the way of time info and
use that exclusively.
It problem seems odd but you can have cases where, e.g., 'sleep 10'
works and date is not right. I had this under both lguest and xen.
On Tue, Aug 4, 2009 at 8:20 AM, ron minnich wrote:
> It problem
probably
sorry
ron
2009/8/4 erik quanstrom :
> do you have something funny bound on /dev?
having said what i said - yes, i realise that a mistaken
bind -b means that i was using drawterm's /dev/time,
not the host system's.
and, oddly, drawterm implements the time
file, but doesn't bother to actually get the correct
2009/8/4 erik quanstrom :
>> fiddle% cat /dev/time
>> 0 0 0
>> 1 fiddle%
> what's especially wrong about this is that /bin/time is supposed
> to have 4 fields:
it does - it just that the line wrapped.
the value of the last field is 1.
> fiddle% date -u
> Thu Jan 1 00:00:00 GMT 1970
> fiddle% cat /dev/time
> 0 0 0
> 1 fiddle%
> fiddle% # wait a few seconds
> fiddle% cat /dev/time
> 0 0 0
> 1 fiddle%
what's especially wr
On Mon, Aug 3, 2009 at 10:56 PM, roger peppe wrote:
> the time problem i was having before (fast clock) had seemed to be
> irreproducible. however just now, i noticed the following
> odd behaviour:
>
> fiddle% date -u
> Thu Jan 1 00:00:00 GMT 1970
> fiddle% cat /dev/time
> 0
the time problem i was having before (fast clock) had seemed to be
irreproducible. however just now, i noticed the following
odd behaviour:
fiddle% date -u
Thu Jan 1 00:00:00 GMT 1970
fiddle% cat /dev/time
0 0 0
1 fiddle%
fiddle% # wait a few
