Re-applied the scripts and all is well now. Once another SQL script comes into the stable branch I will run the upgrade again, something must still be off here. For reference, after a pull, daemon stop, etc. we are only running storage upgrade --force -- is this incorrect? Seems to be fine in our other instances, but for this one the scripts are being marked as applied, but they aren't.

Thanks, I'll look into this further. I didn't install it myself, I'll ask sysadmin permissions to get through the setup personally.

Something else on your server is likely altering URLs. What OS is this? Is this a shared host? Do you have software like apparmor running? All things to look into.

Yup, purging caches didn't help.

Unfortunately, we can't move forward, then.

I'm sorry, other than:

I'm not sure, then. You have the B rule, and your Apache is recent enough to support the B flag.

Closing for now, happy to reopen with reproduction steps we can follow.

Wow, isy is quite a productive little worker!

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

I'll generate a best guess patch later today.

I think it's a race condition with quicksand

@flippingtables: Do you access to your phabrictor intance through a loadbalancer?

Ran into this too.

http2 apache Mod caused this bug.
I disabled http2 mod and everythings fine now

I hope it is clear from the commands and reproduction steps I posted above, that I did not modify the source of Phabricator in any way. I am working with the code straight out of Git, immediately running ./scripts/celerity/generate_sprites.php on it.

I'd be thrilled to answer questions about third-party application development or Phabricator's internals, but unfortunately we can't offer that for free -- it's very time consuming and usually only benefits one user. If you're interested in help with modifying Phabricator or developing third-party applications, see Consulting.

To allow me to debug this further: Is init with config.optional = false supposed to work without a MySQL server? Reading the code I would assume: No, but I want to make sure.

Not having any issues on either of my dev machines either.

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

Complete steps for reproduction on my system:

$ git clone -b stable https://github.com/phacility/arcanist.git
Cloning into 'arcanist'...
remote: Counting objects: 17550, done.
remote: Total 17550 (delta 0), reused 0 (delta 0), pack-reused 17550
Receiving objects: 100% (17550/17550), 6.45 MiB | 1.42 MiB/s, done.
Resolving deltas: 100% (10824/10824), done.
$ git clone -b stable https://github.com/phacility/libphutil.git
Cloning into 'libphutil'...
remote: Counting objects: 14449, done.
remote: Compressing objects: 100% (15/15), done.
remote: Total 14449 (delta 2), reused 0 (delta 0), pack-reused 14434
Receiving objects: 100% (14449/14449), 7.85 MiB | 3.50 MiB/s, done.
Resolving deltas: 100% (8528/8528), done.
$ git clone -b stable https://github.com/phacility/phabricator.git
Cloning into 'phabricator'...
remote: Counting objects: 216912, done.
remote: Compressing objects: 100% (708/708), done.
remote: Total 216912 (delta 323), reused 0 (delta 0), pack-reused 216200
Receiving objects: 100% (216912/216912), 118.31 MiB | 10.88 MiB/s, done.
Resolving deltas: 100% (144506/144506), done.
$ cd phabricator/
$ ./scripts/celerity/generate_sprites.php
[2016-11-15 19:58:29] EXCEPTION: (AphrontConnectionQueryException) Attempt to connect to root@localhost failed with error #2002: No such file or directory. at [<phutil>/src/aphront/storage/connection/mysql/AphrontBaseMySQLDatabaseConnection.php:343]
arcanist(head=stable, ref.stable=e17fe43ca3fe), phabricator(head=stable, ref.stable=fc71a7e92dc2), phutil(head=stable, ref.stable=b10adc2e3f86)
  #0 AphrontBaseMySQLDatabaseConnection::throwConnectionException(integer, string, string, string) called at [<phutil>/src/aphront/storage/connection/mysql/AphrontMySQLiDatabaseConnection.php:76]
  #1 AphrontMySQLiDatabaseConnection::connect() called at [<phutil>/src/aphront/storage/connection/mysql/AphrontBaseMySQLDatabaseConnection.php:101]
  #2 AphrontBaseMySQLDatabaseConnection::establishConnection() called at [<phutil>/src/aphront/storage/connection/mysql/AphrontBaseMySQLDatabaseConnection.php:124]
  #3 AphrontBaseMySQLDatabaseConnection::requireConnection() called at [<phutil>/src/aphront/storage/connection/mysql/AphrontMySQLiDatabaseConnection.php:15]
  #4 AphrontMySQLiDatabaseConnection::escapeBinaryString(string) called at [<phutil>/src/aphront/storage/connection/mysql/AphrontMySQLiDatabaseConnection.php:11]
  #5 AphrontMySQLiDatabaseConnection::escapeUTF8String(string) called at [<phutil>/src/xsprintf/qsprintf.php:178]
  #6 xsprintf_query(AphrontMySQLiDatabaseConnection, string, integer, string, integer) called at [<phutil>/src/xsprintf/xsprintf.php:70]
  #7 xsprintf(string, AphrontMySQLiDatabaseConnection, array) called at [<phutil>/src/xsprintf/qsprintf.php:64]
  #8 qsprintf(AphrontMySQLiDatabaseConnection, string, string, string, string) called at [<phutil>/src/xsprintf/queryfx.php:5]
  #9 queryfx(AphrontMySQLiDatabaseConnection, string, string, string, string) called at [<phutil>/src/xsprintf/queryfx.php:13]
  #10 queryfx_all(AphrontMySQLiDatabaseConnection, string, string, string, string) called at [<phutil>/src/aphront/storage/connection/AphrontDatabaseConnection.php:52]
  #11 AphrontDatabaseConnection::queryData(string, string, string, string) called at [<phabricator>/src/infrastructure/storage/lisk/LiskDAO.php:535]
  #12 LiskDAO::loadRawDataWhere(string, string) called at [<phabricator>/src/infrastructure/storage/lisk/LiskDAO.php:476]
  #13 LiskDAO::loadAllWhere(string, string) called at [<phabricator>/src/infrastructure/env/PhabricatorConfigDatabaseSource.php:18]
  #14 PhabricatorConfigDatabaseSource::loadConfig(string) called at [<phabricator>/src/infrastructure/env/PhabricatorConfigDatabaseSource.php:7]
  #15 PhabricatorConfigDatabaseSource::__construct(string) called at [<phabricator>/src/infrastructure/env/PhabricatorEnv.php:238]
  #16 PhabricatorEnv::buildConfigurationSourceStack(boolean) called at [<phabricator>/src/infrastructure/env/PhabricatorEnv.php:95]
  #17 PhabricatorEnv::initializeCommonEnvironment(boolean) called at [<phabricator>/src/infrastructure/env/PhabricatorEnv.php:75]
  #18 PhabricatorEnv::initializeScriptEnvironment(boolean) called at [<phabricator>/scripts/init/lib.php:22]
  #19 init_phabricator_script(array) called at [<phabricator>/scripts/init/init-script.php:9]
  #20 require_once(string) called at [<phabricator>/scripts/__init_script__.php:3]
  #21 require_once(string) called at [<phabricator>/scripts/celerity/generate_sprites.php:4]
$ php --version
PHP 7.0.12-1 (cli) ( NTS )
Copyright (c) 1997-2016 The PHP Group
Zend Engine v3.0.0, Copyright (c) 1998-2016 Zend Technologies
    with Zend OPcache v7.0.12-1, Copyright (c) 1999-2016, by Zend Technologies
$ php5 ./scripts/celerity/generate_sprites.php
[2016-11-15 20:02:04] EXCEPTION: (AphrontConnectionQueryException) Attempt to connect to root@localhost failed with error #2002: Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2). at [<phutil>/src/aphront/storage/connection/mysql/AphrontBaseMySQLDatabaseConnection.php:343]
arcanist(head=stable, ref.stable=e17fe43ca3fe), phabricator(head=stable, ref.stable=fc71a7e92dc2), phutil(head=stable, ref.stable=b10adc2e3f86)
  #0 AphrontBaseMySQLDatabaseConnection::throwConnectionException(integer, string, string, string) called at [<phutil>/src/aphront/storage/connection/mysql/AphrontMySQLiDatabaseConnection.php:76]
  #1 AphrontMySQLiDatabaseConnection::connect() called at [<phutil>/src/aphront/storage/connection/mysql/AphrontBaseMySQLDatabaseConnection.php:101]
  #2 AphrontBaseMySQLDatabaseConnection::establishConnection() called at [<phutil>/src/aphront/storage/connection/mysql/AphrontBaseMySQLDatabaseConnection.php:124]
  #3 AphrontBaseMySQLDatabaseConnection::requireConnection() called at [<phutil>/src/aphront/storage/connection/mysql/AphrontMySQLiDatabaseConnection.php:15]
  #4 AphrontMySQLiDatabaseConnection::escapeBinaryString(string) called at [<phutil>/src/aphront/storage/connection/mysql/AphrontMySQLiDatabaseConnection.php:11]
  #5 AphrontMySQLiDatabaseConnection::escapeUTF8String(string) called at [<phutil>/src/xsprintf/qsprintf.php:178]
  #6 xsprintf_query(AphrontMySQLiDatabaseConnection, string, integer, string, integer) called at [<phutil>/src/xsprintf/xsprintf.php:70]
  #7 xsprintf(string, AphrontMySQLiDatabaseConnection, array) called at [<phutil>/src/xsprintf/qsprintf.php:64]
  #8 qsprintf(AphrontMySQLiDatabaseConnection, string, string, string, string)
  #9 call_user_func_array(string, array) called at [<phutil>/src/xsprintf/queryfx.php:5]
  #10 queryfx(AphrontMySQLiDatabaseConnection, string, string, string, string)
  #11 call_user_func_array(string, array) called at [<phutil>/src/xsprintf/queryfx.php:13]
  #12 queryfx_all(AphrontMySQLiDatabaseConnection, string, string, string, string)
  #13 call_user_func_array(string, array) called at [<phutil>/src/aphront/storage/connection/AphrontDatabaseConnection.php:52]
  #14 AphrontDatabaseConnection::queryData(string, string, string, string)
  #15 call_user_func_array(array, array) called at [<phabricator>/src/infrastructure/storage/lisk/LiskDAO.php:535]
  #16 LiskDAO::loadRawDataWhere(string, string)
  #17 call_user_func_array(array, array) called at [<phabricator>/src/infrastructure/storage/lisk/LiskDAO.php:476]
  #18 LiskDAO::loadAllWhere(string, string) called at [<phabricator>/src/infrastructure/env/PhabricatorConfigDatabaseSource.php:19]
  #19 PhabricatorConfigDatabaseSource::loadConfig(string) called at [<phabricator>/src/infrastructure/env/PhabricatorConfigDatabaseSource.php:7]
  #20 PhabricatorConfigDatabaseSource::__construct(string) called at [<phabricator>/src/infrastructure/env/PhabricatorEnv.php:238]
  #21 PhabricatorEnv::buildConfigurationSourceStack(boolean) called at [<phabricator>/src/infrastructure/env/PhabricatorEnv.php:95]
  #22 PhabricatorEnv::initializeCommonEnvironment(boolean) called at [<phabricator>/src/infrastructure/env/PhabricatorEnv.php:75]
  #23 PhabricatorEnv::initializeScriptEnvironment(boolean) called at [<phabricator>/scripts/init/lib.php:22]
  #24 init_phabricator_script(array) called at [<phabricator>/scripts/init/init-script.php:10]
  #25 require_once(string) called at [<phabricator>/scripts/__init_script__.php:3]
  #26 require_once(string) called at [<phabricator>/scripts/celerity/generate_sprites.php:4]
$ php5 --version
PHP 5.6.26-1 (cli)
Copyright (c) 1997-2016 The PHP Group
Zend Engine v2.6.0, Copyright (c) 1998-2016 Zend Technologies
    with Zend OPcache v7.0.6-dev, Copyright (c) 1999-2016, by Zend Technologies

I'm happy to work with you to answer questions about my local environment and try to narrow down what's different, but we charge for this because it's very time consuming and often only helps one user. See Consulting for details.

We haven't received additional information that allows us to reproduce this issue, so we can't move forward. Feel free to file a new report in the future if you can provide complete reproduction steps.

I assume you have a MySQL server running on your machine? Thus the connection can be successfully established?

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

In T11856#200111, @epriestley wrote:

Certificates have been deprecated in favor of tokens (they were less flexible, and users frequently found working with them confusing). Everything you describe is working as intended, so this is not a bug in Phabricator. We also don't provide support with third-party code.

If you're using a Zulip binding and its instructions tell you to generate a certificate, they are substantially out of date and won't work for a modern version of Phabricator. If you're using these bindings, they're haven't been updated in more than two years.

You should contact the extension maintainers, not us, for help with their extension or configuration instructions.

In T11856#200178, @mpries wrote:

Hi,

Everything you describe is working as intended, so this is not a bug in Phabricator.

For me it looks like conduit.getcertificate is not working as intended, otherwise it would return a certificate. The current API documentation still contains this method (and there is no notice, that this is deprecated or removed):
https://secure.phabricator.com/conduit/query/modern/

Where would I be able to see, that this call is not working anymore?

Thanks!

Thank you for the response, it is very likely a dup of T9898

From that trace, it's possible that there's an issue in the vein of T9898, if the repository has an enormous number of branches (tens of thousands?).

More detail:

What happened before that?

It's not 'Hanging', it just doesn't appear to be doing with queued tasks and this is the output (repeated ad nauseam)

Everything you describe is working as intended, so this is not a bug in Phabricator.

Certificates have been deprecated in favor of tokens (they were less flexible, and users frequently found working with them confusing). Everything you describe is working as intended, so this is not a bug in Phabricator. We also don't provide support with third-party code.

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

Cool. I'll merge this into T4124 and retitle that to be a little more specific.

I'm quite certain that it's the -L option. Let me talk to the system administrator about installing the GNU diffutils -- I'm guessing that it won't be a problem.

We've only seen that one other time, so it hasn't been a priority to fix. I believe the other install which hit the issue was able to install GNU diff to resolve it.

Yes, I think that it's the same issue as T4124: Test the capabilities of `diff` better, especially for Solaris, as I just found the -L options in generateRawDiffFromFileContent.

Incidentally, this Phabricator installation is running on Solaris (Solaris 11.3) if that makes any difference.

Thanks for the quick feedback. Perhaps it's something unique to my environment because I can reproduce this behavior consistently across multiple repositories.

I can't reproduce this by following the steps provided. Here's what I did:

Could phabricator.base-uri setting affect this? Our install is accessed via http://phab.domain.com:port/.

Our users can confirm this behavior. With active persistent chat, the Lightbox is not working. If it is disabled, its working as expected.

Our users can confirm this behavior. With active persistent chat, the Lightbox is not working. If it is disabled, its working as expected.

seems this is due to I didn't add the --lintall option,
the change is one line removal (existing file at the base commit)
thus it's considered as not concerned, but it is concerned actually because I didn't remove the entire function

That's too bad. I've done some testing and realized that the repositories that are exhibiting this behavior are non-bare, and one older repository that is bare is fully up-to-date in Diffusion's UI. (All are git repositories.)

@rfreebern Nope, no clue how to debug it. We just don't use Diffusion any more and instead use the Bitbucket page, whose UI we anyway prefer to see commits and browse the code :/

@adityar7 Were you ever able to resolve this? I'm seeing the same behavior on my installation, which we recently transplanted to a new server and converted its ancient file://-based repositories to hosted. My suspicion is that there's something not quite right with user permissions on the system, but /var/tmp/phd/log/daemons.log doesn't have anything useful.

I tried stopping aphlict notification server. Stopping it has no effect, the issue still reproduces if I have Persistent Chat enabled.

Yes we are. I can try to stop the notification server tomorrow, will see if that makes any difference.

I'm not finding anything magical that triggers the error at least against this server or my test server. Are you all running notification servers?

@chad I cannot reproduce the issue on this server.

@chad when persistent chat is open here the preview works fine. We also use Mac/Chrome.

Are there errors in the javascript console? I have persistent chat always on, using Mac/Chrome - and haven't ran into this here on this server. Can you reproduce here? A specific task or diff?

@chad
YES! Thank god

@rphl @samr can you confirm if your users were using "Persistent Chat" when they encountered this? I'm trying to find a repro with that but haven't quite yet. It is plausible given the magical nature of Quicksand.

Can you reproduce that on this server? Offhand I cannot, but "Persistent Chat" is Quicksand based, so it make be dependent on a certain way you navigate. Quicksand is an ajax layer we use to build full pages.

Hah, I found out what triggered the error on our installation.

I can't reproduce this by following the steps you describe. Here's a screenshot of this working properly for me:

This is a global javascript behavior, it's not tied to accounts or policy access.

Have the same issue.
Somehow it depends on the user accounts. Some users can do it, some can not. Any idea what userconfig can be causing that?

See Phacility Consulting if you're interested in hiring us to help troubleshoot local issues. Otherwise we need reproduction steps to be complete and reproducible in our own environments if there is a bug present. Unfortunately we're not staffed to provide one on one support like this for free. Offhand, sounds like something is wrong with how JavaScript is getting delivered. Apache config (page modspeed), proxies, anything that alters the packaging should be looked at.

unfortunately I do not know since when it stops working.

I also can't reproduce locally or on Phacility. No other installs are reporting issues. Given Phabricator was not updated and the bug appeared, I'd have to think it's a local issue to your install and not a bug in Phabricator.

Oh, sorry, apparently @chad got this right then and I misunderstood.

To be clear, I started with the Side-by-Side view, which I guess is the default. And I can't return directly to the side-by-side view with the original amount of context after "Show All Context".

Ah. From the workaround ("View Unified", then "View Side-by-Side") I'm guessing the menu maybe isn't refreshing properly somehow, but I'm not sure how to reproduce it given the provided steps.

There isn't enough information here for the upstream to move forward on this ticket. It appears to be a local PHP issue, but without further information we don't know how to detect or warn you about this set up. If you're using PHP7 for example, it's not currently supported. If you're using PHP5.6, make sure XML is enabled.

I confirm, changing All users to Public fixed it. Thanks!

Ahhhhhh, awesome thanks! I'll merge this over.

Sorry I though I was clear on how you could reproduce the bug. I will try again

(off hand this may be a duplicate of T8307)

• "Try arc patch" is vague, I don't know where you're running it
  • Version information is required on reports, I don't know what version your running
  • Observed behavior / Expected behavior - I don't know what the error message was, or what happened, nor what you expected to happen. We expect to get a copy of the error if one was present, etc.

Sorry, these steps are vague and incomplete. We don't take bug reports like this and our documentation at Contributing Bug Reports is very clear on what information is required.

Sorry I though I was clear on how you could reproduce the bug. I will try again

Sorry if I'm not being clear. This is currently not a valid bug report. Please completely and clearly follow the steps in Contributing Bug Reports. The point of this documentation is to reduce the amount of time the upstream spends on bugs. Having clear communication upfront means we don't have to spend 3x the time trying to get the details afterwards.

Applying a patch on the wrong repository.

A solution to what?

I didn't suggest that. A solution can be to not apply that patch and inform the user about that.

Vaguely, it sounds likely you're expecting arcanist to be able to apply multiple patches to multiple repositories, which I don't think is a feature.