Tuesday, May 15, 2018, 7:49:32 PM, Roman wrote:

> Job 1847 ends at 16:44:11 and job 1852 starts at 18:47:46 (and
> actually subsequently dies as evidenced by its stop being NULL).

How do you KNOW that your program didn't spend 2 hours 3 minutes
either not noticing job 1847 had finished, or deciding what to do next
once it had noticed? Do you KNOW, say, that THAT process didn't die
and was restarted?

> Next job, 2283, is started BEFORE job 1852. RunID is INTEGER PRIMARY
> KEY and for this purpose is auto incrementing. Jobs are also running
> on other nodes, therefore runID is not contiguous for this node. 

Job 2283 starts NEARLY 24 hours AFTER job 1852!

> runID      hostname   start               stop
> ---------- ---------- ------------------- -------------------
> 1841       loginnode4 2018-05-14 07:53:42 2018-05-14 10:05:41
> 1843       loginnode4 2018-05-14 10:05:41 2018-05-14 12:18:05
> 1845       loginnode4 2018-05-14 12:18:05 2018-05-14 14:30:50
> 1847       loginnode4 2018-05-14 14:30:50 2018-05-14 16:44:11
> 1852       loginnode4 2018-05-14 18:47:56
> 2283       loginnode4 2018-05-15 18:18:59

> Could it indicate other issues than the clock itself? It is highly
> unlikely that clock happened to jump forward at the time when 1852
> was finishing (at 16:44:11). Time of start of 2283 looks  
> correct, agrees with my watch, because I started this job manually.

> Roman

Regards,
Graham Holden



_______________________________________________
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Reply via email to