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 this should have
been done in commit 6a3f0cd094717e098803f913e76a3499341cdaf3.
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 09:00:00 2022 a vinc17
512 Fri Feb 4 17:12:00 2022 a vinc17
502 Mon Feb 14 23:00:00 2022 a vinc17
503 Tue Feb 15 09:00:00 2022 a vinc17
513 Fri Feb 4 17:24:00 2022 a vinc17
502 Mon Feb 14 23:00:00 2022 a vinc17
503 Tue Feb 15 09:00:00 2022 a vinc17
514 Fri Feb 4 17:26:00 2022 a vinc17
502 Mon Feb 14 23:00:00 2022 a vinc17
503 Tue Feb 15 09:00:00 2022 a vinc17
i.e. in all these cases, the new job was not shown last by atq.
I don't know whether this has an influence.
--
Vincent Lefèvre <[email protected]> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Index: b/atd.c
===================================================================
--- a/atd.c
+++ b/atd.c
@@ -953,7 +953,7 @@ main(int argc, char *argv[])
daemon_setup();
do {
- now = time(NULL);
+ now = atd_gettime();
next_invocation = run_loop();
if ((next_invocation > now) && (!hupped)) {
atd_setalarm(next_invocation);
