Hello everyone, everything good?
Moodle doesn't even load the home screen due to an LDAP connection problem wouldn't be normal behavior, right?
That is, if bind with LDAP does not work, even users with a manual account cannot access it. Nor does the homepage load.
When reestablishing communication with LDAP, the system returns to normal. Has anyone ever experienced this?
I don't think it is normal behaviour but this thread describes a similar problem which was unresolved.
On a test site if I configure LDAP then both LDAP and manual users are authenticated as expected. If I break LDAP by changing Host URL to something that doesn't exist, then LDAP authentication fails but manual users and the home page still work.
Can you tell us the order of the authentication methods? E.g.:
Also, please tell us more about the environment: Moodle version, PHP version, OS and version of the Moodle server.
Hello,
This is order of the methods:
But I think the problem is related to LDAP Enrollment, not authentication. I concluded this now because by disabling the LDAP Enrollment method, navigation returned to normal. It is as if the LDAP subscription plug-in generated a kind of bottleneck in the system.
Now I want to study a way to access logs of PHP processes generated by Moodle. I still don't know how to do this.
I think you're correct. On login the enrolment plugins will update course enrolments for that user. It's not a bottleneck, it's enrol_ldap making what should be a fast query instead being delayed by the connection attempt timing out.
If you want to see PHP error logs, this may help find them. For the web server access logs these will be something like /var/log/httpd/access.log as Emma suggests or /var/log/apache2/access.log. If it's a managed server your provider should be able to help.
Bitnami ...
https://docs.bitnami.com/bch/apps/wordpress/troubleshooting/debug-errors-apache/
might say wordpress in link but a bitnami moodle should use same apache logs.
Since is it Bitnami, have you made use of their forums as well?
https://community.bitnami.com/
https://community.bitnami.com/c/moodle
'SoS', Ken
Hello,
I tried to generate the same behavior in a test environment and apparently the slowness, in fact, has to do with the timeout of the unsuccessful attempt to bind with LDAP. Unfortunately this timeout affects users who are not authenticated by LDAP and in my case, we had a spike in login attempts added to that, which seems to have compromised the entire system.
I am still in doubt about why other Moodle tasks are slow because of this? Is it related to CRON?
As a way around this, I thought about increasing the "task_scheduled_concurrency_limit" or finding a way to reduce the LDAP bind timeout
tail -f php_errors.log
[24-Sep-2020 16:09:59 America/Sao_Paulo] [ENROL LDAP] Inscrever usuário 'prof' no curso 'MOODLE - ESTRATÉGIAS PEDAGÓGICAS E POSSIBILIDADES - TESTE' (id 267)
[24-Sep-2020 16:11:01 America/Sao_Paulo] [ENROL LDAP] Desinscrever usuário 'prof' do curso 'MOODLE - ESTRATÉGIAS PEDAGÓGICAS E POSSIBILIDADES - TESTE' (id 267)
[24-Sep-2020 16:12:12 America/Sao_Paulo] [ENROL LDAP] Inscrever usuário 'prof' no curso 'MOODLE - ESTRATÉGIAS PEDAGÓGICAS E POSSIBILIDADES - TESTE' (id 267)
