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 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.
With the unpatched "at", for 522 Fri Feb 4 17:54:00 2022 a vinc17 502 Mon Feb 14 23:00:00 2022 a vinc17 503 Tue Feb 15 09:00:00 2022 a vinc17 the job was taken into account. But for 523 Fri Feb 4 17:55:00 2022 a vinc17 502 Mon Feb 14 23:00:00 2022 a vinc17 503 Tue Feb 15 09:00:00 2022 a vinc17 it isn't (and it is still in the queue at 18:01). 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 reproduce the bug at all (but why???). -- Vincent Lefèvre <vinc...@vinc17.net> - 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)
