I'm creating a new bug to track this and blocking bug 662444 with it because that bug is many years old at this point, making the conversations in it somewhat dated and difficult to sift through for casually interested parties. I do however recommend anyone who is seriously interested in this project read that bug and its linked bugs in full.

This is intended as a bug tree for implementing and enabling a fast shutdown path on release builds via an iterative approach. We will first consider limited configurations and scenarios, and exit from late in the shutdown timeline, and work our way to encompass most/all configurations and scenarios, and exit from early in the shutdown timeline.

Doug, I wonder if there is something that we can utilize in CI. For a couple of tests we still see long delays during shutdown but test harnesses usually turn off telemetry for automation. So are any files generated and stored in the Firefox profile that might be worth uploading as artifacts to Taskcluster?

(In reply to Henrik Skupin (:whimboo) [⌚️UTC+2] from comment #2)

Doug, I wonder if there is something that we can utilize in CI. For a couple of tests we still see long delays during shutdown but test harnesses usually turn off telemetry for automation. So are any files generated and stored in the Firefox profile that might be worth uploading as artifacts to Taskcluster?

Hmm, the only things I know of are gated on telemetry being enabled. There is ShutdownDuration.json, which records durations of various phases of shutdown, in seconds, and also last_permahang.bin. It could potentially be worth it to extend those checks to some other flag which is on in tests but otherwise mirrors our telemetry settings?

(In reply to Doug Thayer [:dthayer] (he/him) from comment #3)

Hmm, the only things I know of are gated on telemetry being enabled. There is ShutdownDuration.json, which records durations of various phases of shutdown, in seconds, and also last_permahang.bin. It could potentially be worth it to extend those checks to some other flag which is on in tests but otherwise mirrors our telemetry settings?

The only file I can find in normal profile with Telemetry enabled is Telemetry.ShutdownTime. None of your other mentioned files are in any of my profiles. So will those files be deleted when you start Firefox next, or removed after a while? Or where in the profile should those appear?

ShutdownDuration.json AKA TerminatorTelemetry

I'm afraid I know very little about TerminatorTelemetry besides what I've now read in response to your needinfo.

The next run of Firefox does indeed read <local profile dir> + ShutdownDuration.json three seconds after profile-after-change, deleting it immediately after it's read.

FWIW Terminator Telemetry (SHUTDOWN_PHASE_DURATION_* histograms) is old perf Telemetry that has no owner that I know of and might possibly be able to be removed wholesale if we can establish who should own it and get their permission to remove it. :dthayer, you're the closest to an peer of Shutdown in this conversation: do you know anyone using this?

last_permahang.bin AKA BHR

BHR was last touched by mconley's UserInteractions work, so I tag him as perhaps knowing what this is about.

(In reply to Chris H-C :chutten from comment #5)

ShutdownDuration.json AKA TerminatorTelemetry

I'm afraid I know very little about TerminatorTelemetry besides what I've now read in response to your needinfo.

The next run of Firefox does indeed read <local profile dir> + ShutdownDuration.json three seconds after profile-after-change, deleting it immediately after it's read.

FWIW Terminator Telemetry (SHUTDOWN_PHASE_DURATION_* histograms) is old perf Telemetry that has no owner that I know of and might possibly be able to be removed wholesale if we can establish who should own it and get their permission to remove it. :dthayer, you're the closest to an peer of Shutdown in this conversation: do you know anyone using this?

I have never heard of people depending on this? It doesn't strike me as very useful, given the 1s granularity and that if you're looking to diagnose shutdown hangs the crash stacks are far more useful than broad phase timing information. I'm perfectly fine with abolishing it.

last_permahang.bin AKA BHR

BHR was last touched by mconley's UserInteractions work, so I tag him as perhaps knowing what this is about.

last_permahang.bin will only be be present if you had a session that hung for more than 8 seconds and was unable to terminate gracefully during that hang. In our case I suppose that makes it redundant with the crash stack from an nsTerminator timeout.

So... shall I file the bug for removing TerminatorTelemetry, or would you like the honours? I have things on my plate that I won't be able to get to it any time soon, but I can review its removal.

(In reply to Chris H-C :chutten from comment #7)

So... shall I file the bug for removing TerminatorTelemetry, or would you like the honours? I have things on my plate that I won't be able to get to it any time soon, but I can review its removal.

I assume this bug hasn't been filed yet? Maybe you can just do it?

Here you go: bug 1690096. Up for grabs.