alarm(2) - what does it do when someone changes the system time while it's waiting?

Question

The man page says that alarm() arranges for a SIGALRM signal to be delivered to the process in _seconds_ seconds. What happens if someone (such as the user or ntpd) changes the system clock while the alarm is pending? How is the time remaining on the alarm accounted for?

Answer 1

First off, most responsible admins and xntpd are certainly not normally going to adjust time in huge chunks. Doing that breaks cron, for example.

But even if they were to do that, alarm uses setitimer() with ITIMER_REAL - meaning it would still wait for so many clock ticks. Pretend the system clock runs at 1 million Hz, one million ticks per second. Okay, so 2 seconds is 2 million realtime clock ticks, regarldess of what the system time is set to. setitimer() just keeps on decrementing its counter to zero. When it hits zero, SIGALARM is raised. There can be considerable slack on long side of this because other processes could have the cpu. alarm() is guaranteed to go off in a MINUMUM of n seconds - the actual elapsed time could be a little longer.

Messing with system time breaks scheduling software like AppWorx or cron.