Unable to delete container sub-elements: Proxy error

edited March 3 in General Support

Since updating to develop v1.8, I cannot delete container sub-elements anymore. Don't know if it's related to the update, but I never encountered it before. Everything else in Providence works as usual.

When clicking on "Delete", the page loads for a long time - and then (after a timeout?) I get the following error message:


Proxy Error

The proxy server received an invalid response from an upstream server.

 The proxy server could not handle the request

Reason: Error reading from remote server


Any ideas what might be causing this?

Thanks in advance!


  • The proxy error would be due to the request taking too long. So it's hanging. This can be due to many reasons. I'll try it on our test systems and see if I can replicate.

  • Deleting sub-elements works ok on our test servers. Are the elements you're deleting used in a large data set? When they're deleted a lot of database queries are triggered and reindexing run. It's possible these queries are taking longer than the configured PHP-fpm timeout on your web server.

    I've just pushed a change to the search indexer that may help with this. Let me know if it makes any difference.



  • edited March 8


    Q: "Are the elements you're deleting used in a large data set?"

    Hm... you mean if the MD-element I'm modifying is used in many data sets? Indeed it is, since it's a "title" field.

    Where would I increase the php-fpm timeout value? Couldn't find "fpm" in php.ini...




  • Proxy timeout would be set in your webserver (Apache or nginx).

  • We've increased *a* timeout value: The original proxy error seemed to originate between the WAF and the Docker container Providence is running in. The current CA setup doesn't use PHP-fpm but mpm_prefork.

    Now the proxy error is gone, but it seems that it's running into another timeout somewhere in Apache/PHP - and get a "500 internal server error" - but no further information in the logs.

    Is there a way to get more verbose logging messages from providence?

    (btw: We haven't pulled your previous change yet, so we're able to find "which" timeout setting value we're running into)

  • If it's a 500 error it's going to be something the web server returns in its log, not CA. It also might be a seg fault from Apache or PHP, so I'd suggest looking in syslog or equivalent. If this is containerized, there may be other logging locations specific to your environment.

  • @seth: True.

    Sorry for the misunderstanding: I didn't mean that CA should output an error in the UI, but we find nothing in Apache/PHP logs so I was hoping that CA had something like a background logging?

  • Update:

    The php.ini setting that seemed to do the trick was: max_execution_time

Sign In or Register to comment.