sys_timer_getoverrun(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’… sys_timer_getoverrun(9)

okay so this is a page from the Kernel API Manual β€” it's sys_timer_getoverrun, and bestie, we're about to learn how many times a timer said "ding" while nobody was listening πŸŽ€


✨ NAME ✨

sys_timer_getoverrun β€” grab the number of overruns on a POSIX.1b interval timer, fr fr


🌸 SYNOPSIS 🌸

long sys_timer_getoverrun (timer_t timer_id );

that's it. one arg. slay. πŸ’…


πŸ¦‹ ARGUMENTS πŸ¦‹

  • timer_id β€” the timer ID, aka the little name tag that tells you which timer we're talking about 🏷️

πŸ‘‘ DESCRIPTION πŸ‘‘

okay so picture this: a timer's "overrun count" is one plus the number of expiration intervals that have elapsed between the first expiry β€” the one that queues up the signal β€” and the actual, real-life signal delivery. the way that works is lowkey iconic: when the signal gets delivered, the "overrun count" is calculated and cached, so it can just be handed back to you directly right here. no math, no waiting, it's giving prepared πŸ’–

but here's the part where I gotta be honest with you bestie:

as this is relative to the last queued signal, the returned overrun count is meaningless outside of the signal delivery path β€” and even there, it does not accurately reflect the current state when user space evaluates it. 😭 so like… don't trust it too hard. it's a vibe, not a source of truth.

πŸ”₯ RETURN πŸ”₯

  • -EINVAL β€” timer_id is invalid πŸ™ˆ
  • 1..INT_MAX β€” the number of overruns related to the last delivered signal ✨

🫢 SEE ALSO 🫢

  • Kernel file ./kernel/time/posix-timers.c β€” the lore drops here πŸ“‚
  • sys_clock_getres(9) β€” go read your girl's other page πŸ’œ

aaaand that's the whole thing, no cap. this little gem comes to you from ./kernel/time, dated October 2026 β€” so like, future-coded of them ⭐ go forth and check your overruns responsibly, mwah πŸ’‹πŸŒˆ

πŸ“¦ where this page comes from