@michaeljs1990:

do you have any more information from the logs?

Should I post the output from bin/phd log? I can't even tell where the actual logfiles are.

Does /usr/bin/env php -v also print 5.6, versus 7?

can you add --trace to arc, to see exactly what's failing? /api/ is 404ing for good installs too, so I'm guessing it's actually hitting a different uri.

I'm running 16.04 with PHP5.6 as well, haven't seen this issue. Here's my installed PHP info if that helps. Might want to verify what PHP your webserver is running, not just CLI.

do you have any more information from the logs? This also seems like more a question than a bug report since daemons not working right is rather hard to debug.

Server side routing would be my next guess. We regex all urls and map them to controllers internally. Though we should raise a setup warning if they're not set up correctly.

/var/log/httpd/error_log shows nothing with proc_open()

I noticed that my host regex matcher differs from the configuration tutorial found here: https://secure.phabricator.com/book/phabricator/article/configuration_guide/#webserver-configuring-li

I see. Good to know.

Well I typed in one of those...

See T4200 for more details if you’re curious why we don’t currently support
OS packaging / install scripts.

The aur package actually clone from your git, so versioning should not be a problem.

If you try to run /usr/bin/python /usr/bin/hg log --template={node} --rev 'some rev hash' manually in /projects/phabricator/2, does it break or do you get anything useful back?

How can we reproduce this error locally? Bug reports here require reproduction steps, not just the error message.

It might be interesting to have slash-triggers for objects for searching. Right now we don't have a great way (since we have lots of objects) of providing a shortcut.

Well scratch that last comment. It looks like it has pulled in commits from the last 3 days. It looks like under recent commits when I'm viewing the repo doesn't have the most recent commits from 3 days ago, but I just installed a panel on the dashboard showing the most recent commits, and all my commits area there. The panel runs off Audit, and the repo Diffusion.....maybe there's a disconnect? idk.

Also, if you want you can try to install a cert from this server, or from a free instance on Phacility. Just to make sure it's not a server side issue.

https://secure.phabricator.com/book/phabricator/article/arcanist_quick_start/ is our guide, it's just cloning two repositorys and a PATH command, so installation should be simple. No magic.

(the same goes for Phabricator)

We don't maintain or provide any third party packages / installers. They are frequently not kept up to date. Can you install arcanist from our repositories?

I installed the latest arcanist through aur: https://aur.archlinux.org/packages/arcanist-git/

See some discussion in T3945.

What version of arcanist are you running?
If you manually put in the URI, does it work then?

I edited the question to add my configuration of lighttpd. I also changed the address to reflect more the real one.

Ah, true. A correct connection looks like this:

When I type http://myphabserver.com/api/ in the browser, I get the phabricator 404, but I assume that you shouldn't try to request the api in the browser directly.

D16460 is marked as fixing this, and we always send data via Files afterwards. This is different from the approach I'd outlined above (no mode where we continue to return text directly), but two additional considerations have arisen:

Yeah I just double checked, it is a full clone of the original repo at the time it was at, but looking at it now, it hasn't picked up a new commit for 3 days.

Yes, that's correct.

This would be for whitelist/whitelisting IPs. For example creating a security group on AWS that only allows 443 (https) traffic from a phabricator cluster to a jenkins instance.

Than probably not a reasonable case of "too many open files".

Also you can sell No Man's Sky for $60 nowadays so I think the bar has dropped a lot.

Oh! var_dump(...) or print_r(...) should send stuff to a big pink header on the page.

print_r($variable);
look at web page.

@epriestley PHP noob question: what do you do for debugging? I'm having a hard time just looking at the values of the variables involved here:

$pins = $request->getStrList('pin');
$pin = head($pins);
$app = id(new PhabricatorApplicationQuery())
  ->setViewer($viewer)
  ->withPHIDs(array($phid))
  ->executeOne();
if ($app) {
  $pin = get_class($app);
}

we'll discuss internally next week and let you know. thanks for now

You're work-around is fine.
What does cat /proc/sys/fs/file-max say? Is it possible you just have too many open files?

Ah, right -- I think those are both expected and that you're on the right track. You should be able to use $request->getStrList(...) instead of $request->getStr(...) to read the list, then head() to grab the first (item if it exists).

Alright I'm making a bit of progress here. Posting this update on the chance that there's something obvious I'm missing. The AphrontFormTokenizerControl behaves a little bit differently than the AphrontFormSelectControl. Specifically, this is what the form post data looks like the old way (SelectControl):

I'm happy to rewrite your script so it works, but we charge $1,500/hr for custom development (see Consulting) because time spent helping individual users with unique problems takes away from developing and improving Phabricator. Are you interested in this?

this is fine since the way python serializes over HTTP is certainly peculiar; but what about JSON ?

This is not a bug.

This doesn't look like a bug report nor a feature request. I don't know what you want us to do with this.

That doesn't look like a Phabricator 404 page.

Introducing an epoch64 type ends up being pretty messy:

Perhaps a better solution is to introduce an epoch64 datatype and store these timestamps faithfully, since they're at least sort of possible to write and do have a relatively unambiguous meaning. Introducing a new type instead of changing the meaning of the existing epoch would let us accommodate this without requiring tons and tons of migrations or exposing us to a lot of weird fallout.

After some effort, I'm unable to figure out how to generate these commits using vanilla git. I can't figure out how get them with --date or GIT_COMMITTER_DATE to git commit: dates after 2100 are treated like the current date.

I'd be interested in the Refine the workboard/form interaction idea.

Full screen disables live previews in any remarkup box.

I think this task should be reopened, because there is no way to disable live preview in desktop currently.

Developers want to push their local branches to GitHub for a variety of reasons:

• so that if their computer dies, their work doesn't disappear
• so that they can work across multiple machines (eg, if they have a separate computer at home vs at work, or if they have a cloud development environment separate from their local workstation)
• to show their work to other people before sending out a Phabricator revision (which they could still do with Phabricator, but some folks feel like they should only use Phabricator once something is ready for formal review)
• because at a previous organization, they always pushed their branches, so they're in the habit of doing it

Why are you tracking branches you don't want to land onto?

The particular issue is that that the change removed a file containing the bytes ... 0xE5 0x76 .... The 0xE5 is probably an å in Latin 1.

I extracted the response body prior to encoding as a serialized()'d object so I can narrow down what's causing the encoding to fail and it looks reasonable, looking like it's almost certainly a UTF8 issue now.

Not too surprisingly, the response is empty. AphrontResponse->encodeJSONForHTTPResponse() uses json_encode() and does not detect UTF8-related encoding failures, so the chance that this is a UTF8 issue is pretty high. We should also probably fix that so fail earlier and more explicitly (and don't emit HTTP 200).

Oh, so for the hell of it I tried using the cookie data (it's in a username=token format) as the basic HTTP authentication credentials, and it appears to work! I have no idea why Google tries to get you to set up cookies when basic HTTP authentication works just fine.... :/