[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

(monotonic vs wall) clock issues

From: Volker Eckert
Subject: (monotonic vs wall) clock issues
Date: Tue, 29 Dec 2015 20:31:59 +0000

hi all,

consider an embedded system without a real-time clock, on which the wall clock 
is set later (after monit starts). especially in such an environment it would 
be great if monit weren't using the wall clock for time differences, but the 
monotonic one.

in order to achieve that, i wrote the attached patch which might be helpful for 
somebody in a similar situation. it's not terribly well tested and i think it 
won't work on OS X (which doesn't allow pthread_condattr_setclock(), IIRC). i 
wanted to fix that but didn't find time. it should apply against the 5.15 
signed-off-by: volker.eckert <TA>

even if you don't end up applying this, two more independent questions:

1. according to man (5) proc, /proc/<PID>/stat's starttime is in clock ticks, 
so e. g.

s->inf->priv.process.uptime = Time_now() - pt[leaf].starttime;

should have shown a completely wrong value, as Time_now() returns the wall 
(real-) time clock - (how has this ever worked?) - or am i missing something?

2. src/process/process_common.c:get_float_time():
the comment says '@return time in seconds' but the actual value is in units of 
return (double) t.tv_sec * 10 + (double) t.tv_usec / 100000.0;

it might not make a difference, after all, just saying it's confusing.

and lastly a feature request:
there is already 'EXEC' as an action. it would be helpful to have something 
like 'EXEC_ONCE' as well (execute only once), which i had to emulate in a bit 
awkward fashion (in the executed script). maybe there is a better way to 
achieve that, in which case it would be nice if that were more obvious.


Attachment: monit-use_monotonic_time.patch
Description: Binary data

reply via email to

[Prev in Thread] Current Thread [Next in Thread]