`cronnext` reports `nextstring` for every-minute cronjob as beginning of the *current* minute, ie in the *past*. Normal?

So I’m seeing this weird thing (or at least, weird to me, with my tiny amount of experience).

cronnext tells me the nextstring for an every-minute cronjob is the beginning of the current minute,
ie in the past.

eg, if I run cronnext at 02:11:27,
it says:
nextstring: Tue Jul 25 02:11:00 2023
rather than (as I’d naively expect):
nextstring: Tue Jul 25 02:12:00 2023

Is this normal, or…?

Cuz I couldn’t find anything about it in any of the manpages,
and I haven’t been able to google anything up with the terms that I’ve been able to think of…

I added the anacron tag too,
cuz I do have it installed,
although I never used it directly,
so I don’t know if it’s relevant.

$sudo cronnext -c

  - user: "username"  
    crontab: /var/spool/cron/tabs/username  
    system: 0  
      - user: username  
        cmd: "/home/username/my_script.sh"  
        flags: 0x0F  
        flagnames: MIN_STAR|HR_STAR|DOM_STAR|DOW_STAR  
        delay: 0  
        next: 1690276260  
        nextstring: Tue Jul 25 02:11:00 2023  
next: 1690276260  


I’ve already tracked down and fixed the bug I was originally trying to fix when I came across this,
so it turned out to just be a red-herring on that particular issue,
but I decided I still want to ask about it, cuz it still seems weird to me.

Asked By: dwawlyn


The tool doesn’t exist on Debian so I downloaded the latest version, cronie-1.6.1 from its source repository on Github.

The manpage writes in the DESCRIPTION,

Determine the time cron will execute the next job. Without arguments, it prints that time considering all crontabs, in number of seconds since the Epoch, rounded to the minute.

(My emphasis.) It appears that the code always rounds down, which generates incorrect answers such as that which you’ve found.

Here’s how I built it:

./configure --prefix=

And to run it:


A fix appears to be to change the loop starting condition on line 250 of src/cronnext.c that calls nextmatch() to use start+60 rather than start. However, I’m not confident enough of this to submit a patch, and I suspect that fixing start by adding 60 (seconds) where it’s defined on line 344 rather than when it’s used would be better.

Since you use the program, it would be best if you were to submit a bug report on the issue tracker.

Answered By: roaima
Categories: Answers Tags: ,
Answers are sorted by their score. The answer accepted by the question owner as the best is marked with
at the top-right corner.