Bug#1004972: atd forgets to run a job in the queue

On 2022-02-04 18:57:27 +0100, Vincent Lefevre wrote: > 2. Due to the above minor issue, the timer was set at the present >time 18:43:00 (1643996580). But for some reason, the pause() >that follows it is not interrupted. This is the real issue. >This also makes the patched "at" unreliabl

Bug#1004972: atd forgets to run a job in the queue

On 2022-02-04 18:01:34 +0100, Vincent Lefevre wrote: > So it seems that there is some randomness in the reproducibility, > but with the patched "at" and many others tests to try to make > the new job appear at the end (which I couldn't succeed, but this > seems to be useless anyway), I couldn't rep

Bug#1004972: atd forgets to run a job in the queue

On 2022-02-04 17:27:37 +0100, Vincent Lefevre wrote: > It seems to solve the bug, but this is surprising as these functions > should be equivalent. > > However, in my tests, atq showed: > > 502 Mon Feb 14 23:00:00 2022 a vinc17 > 511 Fri Feb 4 17:10:00 2022 a vinc17 > 503 Tue Feb 15

Bug#1004972: atd forgets to run a job in the queue

On 2022-02-04 17:02:08 +0100, Vincent Lefevre wrote: > Well, in the atd source, there are inconsistencies in the time > functions. I can try to have a closer look and make a patch... The attached patch solves an inconsistency by replacing a remaining "time(NULL)" by "atd_gettime()". I suppose that

Bug#1004972: atd forgets to run a job in the queue

Well, in the atd source, there are inconsistencies in the time functions. I can try to have a closer look and make a patch... -- Vincent Lefèvre - Web: 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmetic / AriC p

Bug#1004972: atd forgets to run a job in the queue

On 2022-02-04 16:31:17 +0100, Vincent Lefevre wrote: > The job got run as soon as I submitted a new job. But again, this > new job remained in the queue after the scheduled time. I'm wondering > whether the cause is the existing jobs that are already in the queue, > but scheduled later; there's pos