This hasn't cropped up again and is presumably resolved.

This isn't really resolved, but almost certainly does not make sense to pursue given the Phacility wind-down.

I believe the above changes resolved this, and it hasn't cropped up again.

I believe the above changes covered everything, and there hasn't been any more action on the motivating customer issues, although this isn't terribly meaningful.

I believe D21466 resolved this, since it hasn't cropped up again even though daemon runtimes between restarts have been very long at various periods in the last year.

It's likely that D21451 didn't catch exhaustively all of these, but the motivating use case is now moot. If further need arises somehow, this strategy can be applied to those cases.

This is resolved and/or mooted.

I believe these were all hunted down.

I think this was resolved. I nuked Discourse anyway so it's effectively resolved until another report shows up.

Almost every host currently in production was provisioned with Piledriver and things have been stable for quite a while, so I'm calling this resolved. See elsewhere for issues with Ubuntu20, mail, etc.

I made this change and deployed it to secure, and this "critical security vulnerability" is now a proper Phabricator 404 page:

Calling this resolved, since it has been in production in the Phacility cluster for some time and worked correctly through relevant hardware changes.

Moved the rest of this to T13640.

See also T13646: some very early service calls during initialization currently occur before --trace becomes active. These calls should be visible, possibly by buffering them and then dumping the buffer once --trace comes online.

Browsing Revision

PHP 8.1 disallows strlen(null).

This was resolved by D21452. PHI1880 has some unrelated additional plans.

I deployed this and it seems to be working properly.

Hey, it worked once. Good enough for me!

No dice. We need bin/upgrade to run before mysql because it has to mount the data volume. So now I'm trying this:

... service ... start rather than service ... restart ...

...probably tested...

I deployed this everywhere in the Phacility cluster yesterday and things have been quiet, so I'm assuming it worked until evidence arises to the contrary.

With max_connections at 1024, the server above still looks fine after ~14 days:

D21756 effectively makes all Git pathways call setSudoAsDaemon(true).

Just for visibility, the error messages you'll see if you're affected by this issue look something like this:

...maybe this is an actual bug in Phabricator where some pathways are just missing the "sudo" wrapper?

Elsewhere, I compacted Phacility free instances onto a small number of database servers. I attempted to "fill up" these servers, and succeeded, sort of, but maybe too much -- they eventually fall over and need to be rebooted.

This has some rough edges that I'm not going to deal with for now:

Will this work will with Phabricator?

We came up with a flow in Phorge we think would work well, to progress this task (https://we.phorge.it/E1):

• We'll have a bunch of diffs, on a per-application basis, along the style established here and in D21712.
• We'll review each diff on the Phorge
• When it matures, we'll copy it here for for your review and landing in Phabricator.

Ah thank you!

GitHub was refusing mirror pushes with a credential issue (see also T12896, vaguely). I'm not entirely sure which side of things changed, but the config was set up in a previous-generation way anyway (through a "bot" account instead of a "Deploy Key") so I updated things. Looks like mirroring is back online now and this change has propagated.

@epriestley - the fix for this landed in the master branch but it doesn't look like that has carried over yet into the GitHub mirror which is used as the install location for most users, and is the current recommendation on https://secure.phabricator.com/book/phabricator/article/arcanist_quick_start/. Is there a delay before the mirror observes the changes or does something need poked for it to propagate?

See T12847. All the technical parts of this are now solved except for billing, but since Phacility is winding down I no longer plan to pursue it.

I resolved this in rCORE320b2854.

After T13630:

Only one instance was impacted by this and I just credited them until 2099. I don't currently expect to pursue this.

I no longer expect to pursue this.

• Hosts in the repo class are now build by Piledriver (see T13630), which automatically creates the rbak device entries, so this error isn't likely to occur again.
• I also don't expect to launch any more hosts.

I compacted secure onto new hardware (T13671) and shut down saux001 ("Land Revision") and sbuild001 (Harbormaster remote builds). I think all the remaining work is covered under T13630 (largely, just a handful of large database migrations remain).

I just swapped configs over without merging the LBs, since it wasn't immediately obvious to me what the Application vs Classic state of the world is and swapping was good enough.

The aphlict/notify stuff still needs to be tweaked. I think the snlb + slb setup can be merged into a single slb with "TCP (Secure)" forwarding now.

Databases are moved and secure is out of read-only mode. I'm going to adjust repository configuration, then I should be able to tear down secure001.

I'm going to put secure back into read-only mode now and move the databases to the new host.

I brought up the new host and pointed the slb001 load balancer at it. The database is still on the old host, and the new host doesn't have repositories yet, but the basics seem to be working.

Merging 003 into 001 worked fine with a few expected tricks (e.g., when secure is in read-only mode, you can't push a change to take it out of read-only mode, since pushing is a write). Next up is launching a modern m4.large secure-pool host and then migrating the data.

I'm putting secure into read-only mode now, with the intent of completing steps 1-5 above.

PHP 8.1 changed semantics of static variables in methods. See:

See also T13588. Using static::class to work around changes to the scope of static in PHP 8.1 is also possible now that PHP 5.5 is the minimum version, and some uses of get_class($this) might be replaceable. There's no strong motivator for this, it's just a little cleaner.

See also T13588.

It would still be nice to have this from a completeness/correctness perspective, but other changes have made it less valuable:

...possibly, but not conclusively, a result of an SSH version upgrade...

I put all the database migration stuff everywhere and it appears stable. I'm hooking up Postmark as an outbound pathway now. If I get that working, I'll let it sit for a while and start migrating databases.

Finally, there are other some MySQL version issues which can be avoided with:

The new core/ support for the API is partially deployed; the new services/ support isn't anywhere yet.

See also T13232. Here's a possible build strategy for PHP 8.1 under macOS Mojave. Anyone reasonable should probably give up and use brew instead.