cd provides "at least once" delivery guarantees.
Yeah, I suppose most of my skepticism comes from not knowing any other examples of long-loved processes parsing ps output instead of using PID files.
- Fix typo.
- Fix out-of-date comment/logic around overseer tests.
This whole series of changes is motivated by "a PID file was out of date because of a reboot, and we tried to kill some other random process", right? Was there anything else that PID file tracking wasn't doing correctly?
This incantation seems to work as an upstart job:
I'm going to install an upstart task on secure004 and kick it a few times, some stuff might be sketchy until I figure that out.
Support multiple request encodings (likely BSON, protobuf, or messagepack). Leave JSON as the default, but in cases where messages can not be represented in JSON this gives us a plausible way forward.
The stalled production backup process completed successfully after deploying the change.
See also PHI1318. The new behavior here has tightened our rules about which users we act as.
I'm going to try to sneak this out to the db tier to resolve things before the west coast wakes up, at least.
PHP Fatal error: Out of memory (allocated 311164928) (tried to allocate 105988097 bytes) in /core/lib/libphutil/src/future/exec/ExecFuture.php on line 246
Mon, Jun 24
- Rebase to clear tests.
- Wordsmithing: "any instance" -> "all instances"
Sat, Jun 22
See one followup in T13326. The "import from disk" part seems to have worked properly in production.
Fri, Jun 21
I'm just going to land this as-is pending feedback on actual use cases, anticipating a followup to do parameter/anchor support if some reasonable #comment-123 URI exists in either external system. Then it will at least be easy for us to link-and-preserve-parameters or decline-to-link and we can figure out whatever else arises on a case-by-case basis.
Thu, Jun 20
(Build failure is just D20599 landing out-of-order, oops.)