I've been having a problem with my (development) site hanging when I try to login using LDAP credentials. Using xdebug, I was able to pinpoint the hang to a specific line of code, which is a call to ldap_bind(...). After days of trying to understand why it is hanging, one of my debugging techniques was to disable mod_ldap, and then just try to get any error to show up in apache log (after this has started, apache error logs haven't been recording any errors while performing this http request; It 'hangs' too).
What I did
I disabled the module (sudo a2dismod mod_ldap), restarted the server (sudo service apache2 restart), and confirmed that the module isn't enabled (apache2ctl -M does not show mod_ldap)
The Problem
It still hangs when it reaches ldap_bind(), however, it shouldn't even be reaching that point because without mod_ldap, my code shouldn't even be successfully calling ldap_connect() (right?) which is returning (resource) resource id='5' type='ldap link' (meaning the call was successful). I'm expecting a NoMethod or Function error.
Why can php make a call to a module that isn't enabled, and how do I stop that behavior?
Version
Ubuntu 14.04
Apache 2.4.7
PHP 5.5.9-1ubuntu4.5
Well it turns out, I had a novice understanding of what was happening. Never occurred to me that ldap_connect() as a php call had nothing to do with mod_ldap or any apache module. Thus, disabling/enabling apache mods wasn't doing anything because... it had nothing to do with apache mods.
So... I was able to disable ldap php extension with
sudo php5dismod ldap
and able to check that it was disabled with
php -m
And sure enough, after restarting the server, running my script caused a No function error for ldap_connect() (just as I was expecting/hoping). Now I just need to figure out why ldap_bind() hangs...
Related
I have made a flask application at my local computer in the debugging mode and it runs all fine. But when it comes to production, the website gives me 500 or internal server error, which I have no idea what the bug is. I am fairly new to flask production and this has been stopping me from moving forward for quite a few days.
My questions are:
1> in my local development environment, one could always print things out. But how can I see those prints in the production stage?
2> Do I see them through Apache2 log? Where is Apache2 log?
For production, I actually followed the tutorials from pythonprogramming.net. Youtube link is here:
https://www.youtube.com/watch?v=qZNL4Ku1UQg&list=PLQVvvaa0QuDc_owjTbIY4rbgXOFkUYOUB&index=2
To use a very simple example, if the code imports a package which wasn't installed, where can we see the errors?
Thanks in advance.
I've tried to use to use try ... except block for every flask function. Whenever there is an exception, it can be return to the front-end. But what about other errors?
I found out:
Use logging module
Read apache2 log from /var/log/apache2
On a new installation of cassandra 3.0.20 on redhat 7 I can not list roles. I have tried the option of fixing /etc/alternatives/cassandra/cassandra.yaml with...
authenticator: PasswordAuthenticator
and then restart the service.
still when I run a simple command like LIST ROLES I get the following error.
cassandra#cqlsh> list roles;
Unauthorized: Error from server: code=2100 [Unauthorized] message="You have to be logged in and not anonymous to perform this request"
It turns out that systemctl was not completely stopping cassandra due to weirdness with Redhat 7 and the init file. Therefore the changes to my cassandra.yaml were not taking effect.
Once I killed cassandra, made a proper cassandra.service and restarted the desired settings took effect, and I am able to run operations like "LIST ROLES;" normally.
Run environment ：linux （CentOS 7）, JDK 1.8, & ActiveMQ 5.15
I started Activemq then visit the management page with Chrome，when I try to log in with the default username & password I get the following error;
HTTP ERROR: 503
Problem accessing /admin/. Reason:
Service Unavailable Powered by Jetty://
How can I resolve this problem?
I was getting this same error. It turns out that I had run it as root user originally, then later I stopped it and ran it as a non-root user. Certain data files that had been created and owned by the original root instance were not accessible to the non-root user.
Check the ownership of the files, and change them if necessary to match the user that the broker is running as.
Had the same issue.
Maybe something went wrong the extraction of the package.
I downloaded this:
wget https://archive.apache.org/dist/activemq/5.15.0/apache-activemq-5.15.0-bin.tar.gz
and extracted it with:
sudo tar -zxvf apache-activemq-5.15.0-bin.tar.gz -C /opt
then it worked for me.
My two cents:
I start with the activemq in Ubuntu Repo, but then later change to binary package from official website.
In my case, the repo version left an /etc/default/activemq config file, which runs activemq with user "activemq". It turns out in previous experiments, I did not kill the old processes running under "activemq" when I start activemq under my own user name. There are two activemq processes running under different user names, and when connecting to admin console, I have a 503.
I delete the /etc/default/activemq file, and kill all activemq processes running under "activemq", then restart activemq with my user name, the 503 is gone.
I am using apache Archiva v. 2.2.0 under Windows Server 2012 R2, Java version 1.8.0_60 inside VirtualBox. It used to work for quite a long time before Windows autoupdate.
After Windows autoupdate I am getting an error message when going to archiva url: HTTP ERROR: 503 . Problem accessing /. Reason: Service Unavailable, Powered by Jetty://.
The Apache Archiva service is running. No error logs are generated. Restarting or even reinstalling of the service has no impact.
After rolling back of Windows update I restore the normal operation of Archiva, but mysteriously, just once, i.e. stopping and restarting of Archiva will cause the same HTTP ERROR 503.
The log file do not indicate any problem or error cuase.
Thank you for any tips.
I faced a similar issue.
I restarted archiva using ./path/to/archiva/apache-archiva-2.2.0/bin/archiva console
for you, since you are using windows .\bin\archiva.bat console
In my case I've found out that the jetty configuration file jetty.xml in ARCHIVA_BASE\conf got corrupted.
Solution:
Stop archiva service
Replace jetty.xml with either a fresh one or from last known working
backup. A fresh copy of jetty.xml can be downloaded from archiva web
site as an apache-archiva-2.2.0-bin.zip. File location within the
zip file is apache-archiva-2.2.1\conf\jetty.xml
Start archiva service
For me it was complaining about ClassDefNotFound errors, this was because I didn't set my JAVA_HOME properly (on Mac OS). After fixing this, the program worked. Maybe that was your issue.
I have a Perl web app served by Apache httpd using plain mod_cgi or optionally mod_perl with PerlHandler ModPerl::Registry. Recently the app encountered the error Script timed out before returning headers on some invocations and behaved differently afterwards: While some requests seemed to be processed successfully in the background, after httpd sent status 504 to the client, others didn't.
So how exactly behaves httpd AFTER it reached its configured timeout and sent the error to the client? The request/response cycle is finished now, so I guess things like KeepAlive come into play to decide if the TCP connections stays alive or not etc. But what happens to the running script in which environment, e.g. mod_cgi vs. mod_perl?
Especially in mod_cgi, where new processes are started for each request, I would have guessed that httpd keeps the processes simply running. Because all our Perl files have a shebang, I'm not even sure if httpd is able to track the processes and does so or not. That could be completely different with mod_perl, because in that case httpd is aware of the interpreters and what they are doing etc. In fact, the same operation which timed out using plain mod_cgi, succeeded using mod_perl without any timeout, but even with a timeout in mod_cgi at least one request succeeded afterwards as well.
I find this question interesting for other runtimes than Perl as well, because they share the concepts of plain mod_cgi vs. some persistent runtime embedded into the httpd processes or using some external daemons.
So, my question is NOT about how to get the error message away. Instead I want to understand how httpd behaves AFTER the error occurred, because I don't seem to find much information on that topic. It's all just about increasing configuration values and try to avoid the problem in the first place, which is fine, but not what I need to know currently.
Thanks!
Both mod_cgi and mod_cgid set a cleanup function on the request scope to kill the child process, but they do it slightly different ways. This would happen shortly after the timeout is reported (a little time for mod_cgi to return control, the error response to be written, the request logged, etc)
mod_cgi uses a core facility in httpd that does SIGTERM, sleeps for 3 seconds, then does a SIGKILL.