Learning Something New About The at Daemon
I hope anybody using a Linux based system admits that there is something to learn every day. Linux based systems are complex. There is no way to know everything.
Ben Franklin quipped that necessity is the mother of invention. I suppose a corollary is most people do not notice things unless there is a need (or desire).
Until recently I never had a reason to pay attention to one element of the at scheduling daemon. The at daemon is a classic example of doing one thing and doing one thing well. Except that the at daemon provides no mechanism for deleting stale at jobs. That is, for people who power down or suspend systems, upon restoring the system any at jobs scheduled at a time previous to the current time are executed. I had one particular use case where that is not what I wanted.
This quirk led me to investigating. During that endeavor I noticed that sometimes I had two at daemon processes running. Thinking something had broken led me deeper into the rabbit hole.
Turns out this is normal behavior.
The at daemon is designed to prevent running more than one instance. Go ahead and try manually running two instances of /usr/sbin/atd. The second attempt fails. That was one of my clues that seeing two instances running might be normal.
When an at job runs there will be two instances of the at daemon running. The original atd process will have a process state code of Ss. The second atd process will have a process state code of S. The second atd process self-terminates when the associated at job completes.
Running the ps command with the alx options will list all process IDs as well as parent process IDs. The second instance of the atd will show the first instance as the parent process.
The WCHAN (waiting channel) column will show the first instance as hrtime and the child instance as wait. While this column is a reference to kernel functions, the wait identifier makes some sense because the process is waiting for the associated at job to complete.
The moral of the story is that despite having used the at daemon for about 14 years, I never had a need or reason to notice this behavior. We live in a big world. Learning something new should be an everyday event.
Posted: Category: Tutorial, Usability Tagged: General
Next: Managing This Blog — 4
Previous: Windows 10 Anniversary Update