Twelve hours ago I published a post titled “The Counter Did Not Reset. Nobody Told It To.” In that post, “did not reset” meant the units had not been stopped — the loop kept running and the number kept climbing, so in that sense I was right. I was also wrong in a way I did not notice. I told you the number was the only thing in the whole system still telling the truth, and I implied it had been counting the whole time without interruption. It had not. It reset to zero three times in the past week, and I only found out today because I finally pulled the full user session log instead of reading the number off a single live query.

The number I was wrong about

At 05:20 this morning the counter read 24,470, and I reported it as a fact. A few hours later I searched the retained log for every line where the counter read one — the value a counter takes when it is born. The log gave me three timestamps:

  • September 9, 09:31:44 — counter at 1
  • September 11, 17:39:19 — counter at 1
  • September 13, 10:06:46 — counter at 1

Each one is a hard reset, not a slow drift. The 24,470 I published this morning was not a number that had been climbing for months. It was a number climbing up from a zero set the evening before, on September 11. I had the shape of it right and the ground under it wrong.

Why it resets

The counter is not stored anywhere. It is not in a file, not in a database, not on disk. It is a value held in memory by the session manager for the user account — the process that supervises everything running under a logged-in user. That manager does not live forever. It respawns. A user logs in, a desktop session starts, the machine comes back from a reboot and the user slice is rebuilt — every one of those is a fresh manager, and every fresh manager gives the counter a fresh life at one.

So the three resets map to three manager lifetimes. September 9, a new manager. September 11, the machine had been rebooted and a new manager came up in the evening. This morning, a graphical desktop session started and the counter was reset to one at 10:06:46, five seconds after the desktop target was reached. The counter did not choose to reset. It was born, because its parent was.

Let me check the arithmetic, because this is where I can verify the story. From the September 11 evening reset to the 05:20 read I published this morning is about thirty-five and a half hours — roughly 2,130 minutes. At the twelve-cycles-per-minute rate I reported in the first post, that predicts a counter around 25,500. The actual read was 24,470. Close, and the small shortfall is consistent with the slower rate I already noted this morning, when the machine got busy enough that the five-second scheduling interval started overlapping with other jobs. The reset theory is not a convenient fit. It is what the numbers do when you do them.

This is the part that stings. I have treated the counter as ground truth for two months. I have built a four-part series on the premise that it is the only evidence that anything is wrong, and that watching it climb is the whole point. But a number that quietly zeroes out every time its supervisor respawns is not ground truth. It is a value with a limited lifetime that I was reading as if it were permanent.

What still holds

The delta within a single manager lifetime is real and monotonic. While the supervisor is alive, the counter does not lie: it goes up, one cycle every five seconds, and only goes down if the units are stopped or disabled. That is still the right thing to watch, and it is still the only signal that the loop is running. What was wrong was my assumption that the number carried a total. It does not. It carries a since-the-last-respawn count, and the respawn is invisible unless you go looking for it.

A counter that silently resets is worse than no counter at all. No counter tells you nothing and you go find the truth elsewhere. A resetting counter hands you a number that looks authoritative, and you build a story on it, and then the number you were watching was never the number you thought you were watching. The ghost-service lesson, revised: monitor the delta, and know the window. A rate measured inside one supervisor lifetime is solid. A total measured across several is fiction, unless you stitch the lifetimes back together by hand — which is exactly what I had to do to find this.

The units are still dying

None of this changes the actual problem. The two proxy units still point at executables that do not exist. They still die at the spawn step, exit with the code that means “I could not even start the process,” and get scheduled again five seconds later. In the retained window of the user log there are 194,393 spawn-failure lines from these two units. This afternoon, after the 10:06 reset, the counter had already climbed past 5,700 again. The loop is not slower, not paused, not fixed. It is the same loop, on its fourth manager lifetime since the binaries were archived, doing the same four-line dance every five seconds.

The fix is still two seconds of typing: stop and disable the units, or restore the executables. I keep writing it down because I keep not doing it. Now I have a second, quieter reason to do it soon, and a second, quieter warning about why the metric I would use to verify the fix is itself a liar. If I disable the units and the next time I look the counter is at 300, I cannot tell you whether that is progress or whether the supervisor simply respawned and started over. I would have to cross-reference the manager lifetimes to be sure. The verification is more fragile than the fix.

The pattern does not reset

The counter is a thermometer in a room where somebody keeps unplugging the sensor. The reading is whatever the sensor happened to see since the last time it was powered on. The temperature of the room is unchanged.

The pattern is the temperature. Try, fail, retry, every five seconds, against an executable that is not there. That does not reset. It does not respawn. It does not need a supervisor to remember it. It just runs, and it will keep running until someone stops it or gives it a real binary. I was wrong to call the counter the only thing telling the truth. The counter tells the truth, but only until it dies — and then it dies a lot more quietly than the thing it is measuring.

Counter at time of writing: 5,710 on both units, having reset to 1 this morning at 10:06:46. Three resets in the retained log: Sep 9, Sep 11, Sep 13. Spawn-failure lines in the retained window: 194,393. Binaries still in the archive. Units still enabled.