We have started to encounter this as we use phabricator in a devops environment with many teams from a large organisation.

There are several classes of transaction like this. One is that all actions are restricted:

Will try to get more details for you from colleagues.

(And thanks for providing access to an environment where the issue reproduces!)

@Mnkras, I think I've undone everything I did and terminated all sessions on the host. You can revoke my key at your convenience.

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

I was writing my reply while you were writing the above. Just figured I'd mention it.

Yes, that's synchronous signal handling.

note that in the above we're explicitly handling signals. The signal_dispatch call must be placed inside of some activity loop.

function onsignal($signal) {

echo "Got SIGINT.\n";
  exit;

}

Just found another account disabled couple days ago which also says that doesn't belong to any projects, but some projects list him as a member. So the issue is in current version still present.

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:

Im really not sure, when I run restart this is what my daemon page looks like:

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

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.

I found a workaround in the meantime: Press ` and then space (or any other key). The issue obviously is that ` is being sent like dead (combining) key on en-US keyboard layout.

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

Firefox 44 / Ubuntu 15.04
Firefox 47.0.1 (64) Windows 8.1
Firefox 47.0.1 (64) Windows 10
Firefox 47.0.1 (64) macOS

Ah, then it will be some of our local enhancements... Sorry for bothering then.

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

I can look in more detail when I'm back home. Kids have a picnic today.

That's what I plan. Just tested it on WXPx86 and FF 47.0.1 32bit and it works there.

The next step on this report would be for you to try to reproduce on a different environment.

And FF? And 32 or 64 bit?

Tested 8 and 10. I don't have Win7.

@chad Which version of Win & FF you use?

I can't reproduce on Windows, Chrome, FF, IE with en layouts.

Tested in both en and cs layouts.

/ was removed, see D15976 and the changelog:

In T11105#179265, @hach-que wrote:

This is solved with D11688, but it needs to be turned on globally (at the moment it's a per call option, which was added so that internally our custom unit test runner wouldn't deadlock).

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

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

Got it. Thank you! I just started the reindexing operations recommended in this release so I may leave things be 'til that finishes.

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.

Ok; will let it do its thing then.

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.

Ah, I found the problem in our upgrade script. We run our upgrade in the following order:

Thanks for quick response; hadn't seen this before so couldn't tell how serious the errors were.

Oh, or Apache.

Just rebooted apache once more and things are looking better.

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

Did you restart everything after upgrading? See Restarting Phabricator.

Getting the following when I visit differential/:

For reference, @Danny_B filed a copy of this on HackerOne here so I could award a bounty for it:

Also worth noting is that Content Security Policy (T4340) would have prevented this. CSP is obviously worth implementing, but I believe the last attack it would have prevented was D4534 in January 2013, so it's hard to prioritize if it only defuses one attack every 3-4 years.

The Phacility cluster has been patched.

In the future, please report security issues via HackerOne:

Truly our most useful project.

Wait for it...