I just ran into this for the first time:

I've also never seen anyone use kill -TERM `cat /path/to/pidfile` in real life over some flavor of pkill, which is basically the same thing as "pattern match the process titles".

provided I'm not missing some secret reason to retain PID files.

I've marked D20604 as resolving this; it does so by making bin/phd status report local process status only. I strongly suspect that this is probably a better / less confusing behavior.

• "DEAMONS" -> "DAEMONS"

One inline thing, but the rest of this looks correct as far as I can tell.

I have a patch for this which basically says "don't try to kill any process which doesn't look like a daemon process".

This is probably somewhat entangled with T13253 and/or T11037 and this whole thing is kind of a mess.

We've run instances in the Phacility cluster for a long time now, but this is generally not something we really support or plan to support since there's no real customer interest in instancing Phabricator.

Builds have a hard dependency on D20597.

The power is in my hands, now.

But wait! It says there are two ways! The other way is:

If you are just writing an upstart job that needs to start the service after the basic facilities are up, either of these will work:

start on (local-filesystems and net-device-up IFACE!=lo)

This was effectively resolved in 2019 Week 17 (Very Late April). Now, only ancestors of "Permanent Refs" trigger any publishing behavior (audits, notifications, feed, etc).

This is very old and it doesn't look like we ever found a working set of reproduction steps.

To avoid the extreme case of ComComComJava-itis we could maybe just drop the word Configuration from these classes? No other type of EditEngine ... Transaction is ever likely to exist or make sense.

🐫 Does this button work ------>>^^^

There are a few pieces here, since we have to thread the needle through many layers to get where we want to go.

If JIRA links are mostly/all in the form ?page=com.jira.jira.plugin.extension.gateway-to-realms-of-wonder&exec=rm -rf / that might also mean that "links which don't really link to the task" are common and that "task + params" is more like "portal to arbitrary plugin behavior", although I'm not having much luck digging up more information about this by Googling.

Also, practically, I can't actually figure out how to get either modern JIRA or Asana to generate any URI with any parameters or fragments at all. Neither appears to support linking directly to a comment.

I guess my assumption is that ?a=b may, in the general case, completely change the meaning of the link. Although I think this has mostly been purged from the web now, an example was #! fragments before the widespread use of the history API, where https://example.com/a/#!b actually meant "Page B", not "Page A", and labeling the link "Page A" would be misleading.

It's meaningfully more work, but the bigger thing stopping me is that I'm not sure what the best display behavior is.

See also T13317.

See PHI1312. The modified JIRA rules reportedly misfire on URIs with anchors or parameters. For now, the plan is to just skip these URIs. In the future, we might specialize URIs which (for example) link to comments on foreign objects.

I'm going to close this in favor of T13291. Referencing files by full URI currently works, and relative references and other behavior is planned.

Getting rid of the indirect writes on handle reads would probably be nice eventually, but doesn't directly accomplish anything today.

I think that might be everything? Not entirely sure, but haven't seen any more since the last deploy.

D20573 has one issue where the "Select" buttons in the "Merge Duplicates In" dialog are now closing the dialog. We might be missing a JX.pass() / e.prevent() (hopefully) or might need to get slightly more creative in distinguishing between navigation links and javascript magic links.

Yeah, there's a lot of very ambiguous behavior here in the face of ambiguous inputs. I think we're probably not walking into too much of a minefield, but I'm not confident I picked the best behavior for all malformed/suspicious inputs.