CODEWITHSUNDEEP
plone
Pierre Thibault
Pierre Thibault

Reputation: 2073

Unable to request a user password reset

I am in Plone 4.1.6, if you go in Site setup > Users and Groups and then click the checkbox "Reset Password" for a user and click "Apply changes", than the system hangs and after 5 min I have this error from Apache:

Proxy Error

The proxy server received an invalid response from an upstream server.
The proxy server could not handle the request POST /@@usergroup-userprefs.

Reason: Error reading from remote server

Apache/2.2.22 (Ubuntu) Server at 192.168.1.4 Port 443

After the error, I have to restart Plone to make Plone respond again.

My Environment:

As I know, everything is working fine with my Plone instance including the other checkboxes available in Users and Groups.

I did a test with ssmtp to send an email to myself from my node on the vm and I have no problem sending the email.

I did try fg mode and everything seems OK.

I did check the Apache logs and everything seems OK too.

If a create a ssh tunnel to avoid Apache and access Plone directly, I don't have a proxy error but the system hang forever.

I don't know what to do to solve this stuff problem. Any idea?

Upvotes: 1

Views: 396

Answers (1)

izak
izak

Reputation: 583

Does the python process use a lot of CPU when it hangs? Check using top.

Install ZopeHealthWatcher, then when it hangs again, use zope health watcher to get a list of what each thread is doing. That will often give you an idea of where the code is sitting either in a loop, in infinite recursion of some sort (this can happen in the zodb, especially with acquisition and similarly named things), or if it is merely blocking on something (eg, mtu issues on the network link to the smtp server for example, so small emails work but big ones hang).

You could also stop the smtp server (or just change the port in the plone control panel) and see if you at least get an exception out of that. Plone should, by default, raise an exception if it cannot connect to the smtp server.

In really extreme cases, you can use gdb to connect to the hanging python process (I usually use "top" to find the one sitting at 100% CPU), and you could then find where it is hanging. This is a lot more complex than using ZopeHealthWatcher, but I successfully traced a hang to a race condition in reportlabs font code recently using precisely this method, it is very powerful. What is nice about gdb, is it stops the process and allows you to step through the code, and up and down the calling stack, unlike ZopeHealthWatcher which just gives you a snapshot (a bit like that Heissenberg uncertainty thing, you can observe where it is now...)

Upvotes: 1

Related Questions