T11270 describes a major issue with asynchronous signal handling in PHP 7 which I don't believe we have a reasonable workaround for.

Yes, that's synchronous signal handling.

Yes, this reproduces on a local build of PHP 7.0.8. Here's what I did:

I'm building PHP 7.0.8 locally. In the meantime, I found these possibly similar reports:

Here's a smaller, self-contained test case:

I produced this test script to try to see about version issues via 3v4l.org, but you can't write files there. Requiring C as part of a different file is important, so I don't see a way to use that.

I put the global signal handler in run(), unresponsive.

I no-op'd the constructor and put the logic in run(), still unresponsive.

I disabled the entire actual daemon behavior, still unresponsive.

Removing the SIGINT handler entirely made it responsive.

I changed the SIGINT handler to exit immediately, still unresponsive to SIGINT:

This trivial script works correctly:

The PhutilNiceDaemon daemon also does not respond to ^C.

The debug daemon does not appear to respond to an external SIGTERM (via kill <pid> either).

With --trace, the daemon isn't doing any work, and also isn't hung (just normal queries to look at the queue).

I ran bin/phd stop and saw similar behavior:

@Mnkras gave me access to the host.

I can't reproduce that either:

I can't reproduce this. Here's what I did:

Just file a new task once you have the necessary information.

This didn't have a reliable reproduction case, but from limited spot-checking of production logs I don't see it happening any more.

We need a root problem description to move forward here.

@avivey's answer is correct.

Thanks for the report! I think this should be fixed in HEAD of master. Let us know if that doesn't work or you run into anything else.

https://secure.phabricator.com/book/phabricator/article/diffusion_managing/#branches

Turns out that CustomFields sort of just work properly with EditEngine out of the box, so D16226 provides a technically-functional dashboard.panel.edit, which allows you to edit text panels like this, for example:

I don't think there's anything about this specific to Dashboards.

We haven't seen other confusion about this in context.

In the future, we might reasonably want to put tabindex="1" on the first input on form pages, like the "Edit Task" page, so that you could press tab once to quickly begin editing. If we put tabindex="1" on global search, the cost of making this change in the future will be much higher.

Phabricator has no such sidebar item. Where are you seeing this?

Can you substantiate "f" being "typically used"? Here's what I see in use in the wild from a quick survey of popular sites and software:

This feature has a tiny impact and a huge support cost.

See discussion in D15984.

/ was removed, see D15976 and the changelog:

We probably need to do almost all of this work before adding new panel types anyway, since building a new panel type on top of CustomFields would make moving everything from CustomFields to EditEngine harder.

In T9360#183602, @chad wrote:

Is [HTTPS] simple? Not sure where to start? Nothing is jumping out at me here.

The actual panel transactions that we need to update for this aren't too bad. The board transactions are a little more involved, but we can skip them.

This could still be improved, but the immediate confusion we encountered appears fixed.

We can fix the highly-tractable web UI part, at least.

(Just bookkeeping; there's no external priority on this.)

I'm moving this to "Rugged Terrain", as the best available pathway forward leaves us with dramatically higher implementation cost than the reasonable value of the feature. We can pursue this after tasks with better aligned costs and value are addressed.

Mooted from a prioritization standpoint by D16139.

That sounds good to me, should give us more clarity around the dashboard stuff.

When you're editing a homepage dashboard, just having a spacer bar there for the applications menu might help make it more clear that 66/33 is better in a lot of cases than 50/50 -- currently, you can't see what stuff will really look like until you're already done and installed.

wow pretty sure I even picked numbers that add up to 100%

I definitely think we should skip the 3-column versions for now, I don't think we've seen any kind of need for them in practice. We could look at it again after Facts since I think some of these weirder things could make more sense on standalone dashboards, the app just isn't powerful enough yet for that to be paritcularly useful.

Do you think 50/50 and 33/66 are always bad even for standalone (not-on-homepage) dashboards? e.g., if we had a "Phacility Metrics" dashboard in the future after Facts, a 50/50 of a "Users" column and "Revenue" column or whatever could never be a useful way to present the information?

Haha, that's probably T10612.

Why do you think installs (offhand: Babel, WMF) are picking 1/2 + 1/2 if they're strictly worse than 2/3 + 1/3?

You're the only user we're currently aware of who wants to use the software like this, so I don't plan to address this use case at this time.

But when I am looking at my calendar app, I want to see local times, for whatever timezone I am in.

they won't not exist

"Ignored" in the sense of: no publishing, no herald rules, no audit triggers. Not, like, "they won't not exist".

Only that any legitimate commits pushed until things catch up will also be ignored. The repository will automatically leave the mode once everything finishes.

There was a relatively recent change to make Phabricator discover commits which are only reachable from tags and refs. As it discovers these commits, it will treat them like new commits and publish feed stories about them. This is a one-time event, but a few installs have a lot of tag-reachable commits for whatever reason. You can find a bit more discussion in T11188, and details about the change in T9028 and T6878.

This doesn't appear to even to be possible in Firefox. Here's a simple example:

Oh, or Apache.

Also likely fixed by restarting PHP-FPM, that method is defined here:

Did you restart everything after upgrading? See Restarting Phabricator.

From the Firefox bug and this linked one:

This appears to be stable, and is now accounted for.

This seem quiet and is now accounted for.

This appears functional and is now accounted for.