We actually just ran into a situation where this would be extremely useful. We're adding a rudimentary start/end time tracing listener so we can keep tabs on our service calls. That listener uploads the data to an endpoint using an HTTPSFuture, but we want to configure it to not show up in the default echoListener (or to not be profiled at all).

We haven't seen any PHP7 issues in ~6 months and the last few have been very minor things with edge cases like error handling behavior, so I think we can safely call this resolved.

We could probably clean this up (it does look a lot like an error) but DarkConsole isn't exactly a shining example of perfect visual design anyway and I'll probably remember or catch this when it next gets a cleanup pass, some time in 3050.

Yeah it does, and I just didn't recall ever seeing this behavior and assumed "stack trace" meant "error".

(Yell if I'm assuming too much here.)

Via PHI773, filter_input_array(INPUT_ENV, FILTER_UNSAFE_RAW); does not appear to work if variables_order excludes E.

In T8510#200946, @aklapper wrote:

In https://phabricator.wikimedia.org/T76732#2803813 ksmith brings up that "In the search bar in the toolbar at the top of the screen, searching for "Maps" brings up Maps as the third option. Searching for "Discovery" brings up Discovery as the second option."

Can't wait for "connect 2" to come out on playstation six.

Also, when you global-search for an object PHID, we should maybe start taking you to the developer view instead of the main object page.

Ah, nice. Yeah, P2080 looks pretty much like the start of what I'm thinking here.

I have P2080 and P2081 for this :)

To the issue in PHI699 in particular -- finding workboard column PHIDs -- a "Developer View" in the workboard "Manage" menu to take you to the project developer view, plus a "Workboards" section or EngineExtension would probably fit the bill.

Maybe something like this gorgeous mock which I only spilled a little water on:

I added a linter and I accidentally included this line which references a different already-existing linter

final class ArcanistChmodLinter extends ArcanistLinter {

validation for the configuration option

As a general update here since a couple installs are keeping an eye on it, I have a big chunk of the "use instance.state for everything" diff written, but some of the caching logic is tricky and I haven't had a solid chunk of uninterrupted time to stare at it in the last couple days so I don't expect to get it out in time for the release this week.

Hmmm, then maybe the narrowest way to solve this is to just setup disk space alarms. That's a thing we'd want independent of how we eventually build the One True Logging System. The CloudWatch agent collects disk stats out of the box, and takes a list of mountpoints to track. Details here: https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Agent-Configuration-File-Details.html

I think "run weekly with the deploy" already works pretty well for normal log rotation with logs on local disk, and in a perfect world logs would be buffering on disk only briefly before being sent over the network to dedicated log service so we wouldn't need cron there either.

How often does the size directive in a logrotate script get evaluated?

Yeah, I think "solve it forever" is probably "first-party Sentry-like application", this just seems like a problem that should have a 15-minute "solve it for now" solution in the form of something that gives us "a thing that looks like a disk but never fills up" that will hold for a year or two until we build "Phentry".

That makes sense. I was coming at it more from the direction of “if we’re going to touch logs, lets solve it forever”. How about we make everything log locally through syslog and use logrotate to avoid filling disks? Then we can come back and point syslog at something more elaborate later without having to touch all the things that currently generate logs.

I believe there are zero or nearly-zero actionable errors in the log today and that if we had a perfect Sentry-like system it wouldn't actually help us identify or fix any errors -- we'd just ignore it after a week like we currently ignore all the other production error logs.

There's some flavor of bin/remote ssh <some-host> -- tail -f <some-log_location>.

The "logs fill up disks" problem is more "sudden bursts of unusual error/activity that cause log rates to increase 1000x+ fill up disks", not "logs don't rotate / normal log volumes fill up disks". Most logs do already rotate today, I think with the exception of the aphlict log being a bit of a weird case, maybe.

phage tail <some-instance-name> <some-log-type>

But I don't think this is too valuable if it doesn't solve the "logs fill up disks" problem -- does the agent rotate/reap the logs?

In my mind, the only real problem here is...

Possibly something dumb like "mount an EFS volume on /mnt/logs/ on every host" is another AWS-only approach. That feels really dumb but maybe it's only somewhat dumb?

I'm fine with CloudWatch logs, I didn't realize it had a logging thing. I'm currently not terribly warm on investing a ton in CloudWatch alarms or log analysis, but if we can get logs reliably streaming into some storage service so they can't fill up the disk I think that's quite valuable on its own. We can always replace that with something we control directly in the future if we want to invest more here. I can't imagine ever really caring about old logs no matter what happens in the future.

I definitely don't want to send logs to a third-party service.

I'd like to analyze data on the $5 tier with an eye to removing it. Anecdotally, this doesn't seem to be doing anything good for us ... It also feels like we have a lot of $5 test instances.

The UI and allocation logic for shards need tweaking.

See also T13102/PHI442. The MySQL setting optimizer_search_depth=0 may fix the weird explosive complexity here.

I don't run my Phabricator instance on Ubuntu but instead on RHEL6 (and with PHP7, which I know isn't officially support)

This was largely tackled above.

(I'll follow up in T13102 if there's more to be done here, it's possible that some installs are missing this for reasons other than "Ubuntu + apt get install php5-mysql").

(This still needs documentation and validation for the configuration option before it's done, but I don't have any short-term plans to pursue those.)

To customize this:

Safari, Chrome, and Firefox all seem fine with PNG icons so I think we don't need to deal with actual .ico icons.

When phage is executed against a large number of hosts, a bunch of the processes fail immediately. This is likely easy to fix, either some sort of macOS ulimit or one of the sshd knobs. This isn't the limiting factor in any operational activity today but will be some day.

This log is now available at HEAD of master.

See PHI372 -- setting user.custom-field-definitions (or, probably, any similar config) to a string will pass validation but then fatal in use.

Mooted by the switch to prose diffing.