Another open question is: before we call posix_isatty(STDOUT), how do we test whether STDOUT is a valid handle?

I believe the above changes resolved this, and it hasn't cropped up again.

I believe D21466 resolved this, since it hasn't cropped up again even though daemon runtimes between restarts have been very long at various periods in the last year.

This was resolved by D21452. PHI1880 has some unrelated additional plans.

Although I didn't look particularly hard, I can't immediately find any more evidence that this is occurring in production.

When we are importing a commit, we often don't have any legitimate user to act as: the commit may come from an observed repository (so we never authenticated a pusher), and the "Author" and "Committer" strings are arbitrary and untrusted in Git and Mercurial.

All three of these are almost certainly diffusion.rawdiffquery, I think the first one just predated D21463 reaching production so it didn't show the method.

Update the daemon UI to break tasks down by object/container.

See T13591. Tasks now (may) have a containerPHID, and whatever daemon console changes are made in service of dynamic generation should also expose container objects.

After D21518:

These parts seem likely resolved once I convince myself the patches so far actually work:

I have a change to add containerPHID locally, but it ends up having relatively high complexity because several other patches (including 20190909.herald.01.rebuild.php) call PhabricatorRebuildIndexesWorker::rebuildObjectsWithQuery(...), which does not work if executed in sequence prior to a worker queue schema change.

This also relates slightly to T13580, but I believe the two issues are addressable independently.

However, I'd like to have a better understanding of how we're reaching this state, and I'm not satisfied that these repositories are going down the "natural" pathway (of changing ref definitions after the import starts) and suspect there is some more complicated interaction at play here.

I'm hoping to land at least a narrow fix for this today to support an import in PHI1979 tomorrow. However, I'd like to have a better understanding of how we're reaching this state, and I'm not satisfied that these repositories are going down the "natural" pathway (of changing ref definitions after the import starts) and suspect there is some more complicated interaction at play here.

I know it's an old thread, but I am encountering what is, as far as I can tell, exactly the same issue. I'm on the latest version of trunk (~Oct 26) with php 5.5.9 on Linux 3.13.0. I also observed the issue on the May 30 version.

This synthetic script demonstrates the conceptual problem with FutureIterator:

In D21426, I removed phd.trace and phd.verbose.

The call sequence here is approximately:

This appears stable.

This stuff is all deployed, now.

cd provides "at least once" delivery guarantees.

cd provides "at least once" delivery guarantees.

I just ran into this for the first time:

I've also never seen anyone use kill -TERM `cat /path/to/pidfile` in real life over some flavor of pkill, which is basically the same thing as "pattern match the process titles".

provided I'm not missing some secret reason to retain PID files.

I've marked D20604 as resolving this; it does so by making bin/phd status report local process status only. I strongly suspect that this is probably a better / less confusing behavior.

I have a patch for this which basically says "don't try to kill any process which doesn't look like a daemon process".

This is probably somewhat entangled with T13253 and/or T11037 and this whole thing is kind of a mess.

We've run instances in the Phacility cluster for a long time now, but this is generally not something we really support or plan to support since there's no real customer interest in instancing Phabricator.

Some old migrations call PhabricatorSearchWorker::queueDocumentForIndexing(). This no longer works after D20200 because the PHP implementation expects a dateCreated column to exist, but it won't exist until 20190220.daemon_worker.completed.02.sql runs.

I'm looking at these storage/backend changes: