500 error on php.index

96 views
Skip to first unread message

Tony

unread,
Jun 21, 2018, 3:22:22 AM6/21/18
to ica-ato...@googlegroups.com

After working successfully for a few weeks my atom installation has failed.
Logging into the index page results in a 500 error

A server shut down and restart occurred around the time of the failure, but I'm not sure that it's related.
Apache has been restarted a number of times without noticeable effect.

Following the procedures on the trouble shooting page I restarted all the services mentioned (except the job scheduler) with no obvious effect.

I'm running atom 2.40 using Apache on Ubuntu 14.04

I then

Still no change.
Attempting to access the index page results in records in the access log, but nothing in the error log.

Note: I overlooked configuring the job scheduler after installation, but think it's better to get atom working again, and configure the job scheduler afterwards.


Any help would be much appreciated

Thanks

Tony


Dan Gillean

unread,
Jun 21, 2018, 12:52:23 PM6/21/18
to ICA-AtoM Users
Hi Tony, 

There *should* be something that can tell us more about the nature of the error in the Apache error logs. Accessing them will depend on your setup, but it should look something like this: 

Can you share the details of the error message you find there with us? Hopefully that should give us a bit more insight. 

Also, though I don't think it's the cause of this error, the job scheduler has become a core component in 2.4, so I would suggest getting that set up soon - it's used for publication status updates, move operations, exports and imports via the user interface, rights inheritance management, and more. 

Regards,  

Dan Gillean, MAS, MLIS
AtoM Program Manager
Artefactual Systems, Inc.
604-527-2056
@accesstomemory

--
You received this message because you are subscribed to the Google Groups "AtoM Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ica-atom-users+unsubscribe@googlegroups.com.
To post to this group, send email to ica-ato...@googlegroups.com.
Visit this group at https://groups.google.com/group/ica-atom-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/3e34b920-cc2f-2db3-48a1-840369d87b25%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Tony Bazeley

unread,
Jun 22, 2018, 3:56:20 AM6/22/18
to ica-ato...@googlegroups.com
Thanks Dan,


Attempting to access the index page results in records in the access log, but nothing in the error log.
Confirmed by renaming index.php to index.###,  resulted in the error log entry below

[Fri Jun 22 17:05:07.509317 2018] [:error] [pid 12513] [client 118.211.21.11:36386] script '/home/hracag/web/atom/index.php' not found or unable to stat

Seems the request is getting to index.php but not being acted on.
The 500 error response is relatively quick - no sign of a timeout

Tony
To unsubscribe from this group and stop receiving emails from it, send an email to ica-atom-user...@googlegroups.com.

To post to this group, send email to ica-ato...@googlegroups.com.
Visit this group at https://groups.google.com/group/ica-atom-users.

Tony

unread,
Jun 22, 2018, 8:02:48 PM6/22/18
to ica-ato...@googlegroups.com
Thanks Dan,


Attempting to access the index page results in records in the access log, but nothing in the error log.
Confirmed by renaming index.php to index.###,  resulted in the error log entry below

[Fri Jun 22 17:05:07.509317 2018] [:error] [pid 12513] [client 118.211.21.11:36386] script '/home/hracag/web/atom/index.php' not found or unable to stat

Seems the request is getting to index.php but not being acted on.
The 500 error response is relatively quick - no sign of a timeout

Tony

On 22/06/18 02:22, Dan Gillean wrote:
To unsubscribe from this group and stop receiving emails from it, send an email to ica-atom-user...@googlegroups.com.

To post to this group, send email to ica-ato...@googlegroups.com.
Visit this group at https://groups.google.com/group/ica-atom-users.

Dan Gillean

unread,
Jun 25, 2018, 1:24:46 PM6/25/18
to ICA-AtoM Users
Hi Tony, 

Hmmm, strange. I would be suprised if this was the issue, but what browser are you using, and have you tried a different one? Have you tried accessing the site using an incognito/private browser window, to make sure that the browser cache is not complicating the issue?

If there's nothing in the error logs, then we might see if a stack trace will get us more information. Have you tried putting the application into Debug mode? See: 
If you get a stack trace of the error when logging in, please feel free to share it here. 

I would also suggest that you double-check if there are any firewalls or other local installation configurations that might be interfering with access. 

Are you using an HTTPS connection? Does your site have a proper SSL configuration? If not, we have seen cases where people have accidentally turned on the "Require SSL" setting in Admin > Settings > Security when they do not in fact have SSL properly configured, and have as a result been locked out of their application. There is a post here that will tell you how to use SQL to check and change the setting, if this is the case:
I have no idea if this could be a cause or not, but I wonder if incorrect filesystem permissions somewhere could also result in this error? All of AtoM's files and subdirectories need to be owned by the www-data user if you've followed our recommended installation instructions. You can try resetting them with the following command: 
  • sudo chown -R www-data:www-data /usr/share/nginx/atom
Otherwise... I'm not sure. Just so we can cross off some of the obvious troubleshooting steps, I would suggest that you look into the sections on restarting services, and common maintenance tasks on our troubleshooting page: 
  • Rebuild the nested set
  • Generate slugs
  • Clear the application cache
  • Restart services (Nginx, memcached, PHP-FPM)
  • Re-populate the search index
Finally, you could also try creating a new Admin user from the command-line, and logging in with that account, to make sure the issue with not with that particular user. See: 
See if any of that helps - mostly, we are starting with the common solutions to reoccuring problems, to see if we can narrow down the cause. Let us know what you find. 

Regards, 


Dan Gillean, MAS, MLIS
AtoM Program Manager
Artefactual Systems, Inc.
604-527-2056
@accesstomemory

To post to this group, send email to ica-atom-users@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "AtoM Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ica-atom-users+unsubscribe@googlegroups.com.
To post to this group, send email to ica-atom-users@googlegroups.com.

Visit this group at https://groups.google.com/group/ica-atom-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/ee0d6554-b454-c7b4-ba16-6ee147888a83%40sa.apana.org.au.

Tony

unread,
Jun 27, 2018, 3:09:38 AM6/27/18
to ica-ato...@googlegroups.com
Thanks Dan,

I've worked through the suggested approaches below, with unfortunately no resolution to the problem.

I did discover :
  1. The mysql database had stopped.
    I was able to get it restarted, and restarted and restarted the services suggested below, but still have not resolved the problem

  2. The log_errors flag in the /etc/php5/php.ini  file is set to on.
    However a file with a call to php_info in the atom directory reports the log_errors flag is Off
    I don't know php very well at all but am wondering if atom downstream settings are controlling this flag, thus blocking transfer of errors to apache's log mechanism
Tony


On 26/06/18 02:54, Dan Gillean wrote:
Hi Tony, 

Hmmm, strange. I would be suprised if this was the issue, but what browser are you using, and have you tried a different one? Have you tried accessing the site using an incognito/private browser window, to make sure that the browser cache is not complicating the issue?
I've used both Firefox and Chromium ; Firefox doesn’t pick up the 500 error at all.

Have also used wget :

wget http://hracag.org.au/atom/index.php
--2018-06-26 14:38:02--  http://hracag.org.au/atom/index.php
Resolving hracag.org.au (hracag.org.au)... 203.14.158.10
Connecting to hracag.org.au (hracag.org.au)|203.14.158.10|:80... connected.
HTTP request sent, awaiting response... 500 Internal Server Error
2018-06-26 14:38:02 ERROR 500: Internal Server Error.


If there's nothing in the error logs, then we might see if a stack trace will get us more information. Have you tried putting the application into Debug mode? See: 
If you get a stack trace of the error when logging in, please feel free to share it here.

Have followed the instructions in the "editing the  index.php  file" section
No stack trace is returned


I would also suggest that you double-check if there are any firewalls or other local installation configurations that might be interfering with access.
The request is logged in the apache acess.log and requests to a php.info file in the same directory are successful, so I'm assuming it's not a firewall issue


Are you using an HTTPS connection? Does your site have a proper SSL configuration? If not, we have seen cases where people have accidentally turned on the "Require SSL" setting in Admin > Settings > Security when they do not in fact have SSL properly configured, and have as a result been locked out of their application. There is a post here that will tell you how to use SQL to check and change the setting, if this is the case:
Https is not currently used


I have no idea if this could be a cause or not, but I wonder if incorrect filesystem permissions somewhere could also result in this error? All of AtoM's files and subdirectories need to be owned by the www-data user if you've followed our recommended installation instructions. You can try resetting them with the following command: 
  • sudo chown -R www-data:www-data /usr/share/nginx/atom
Everything looks to be owned by www-data, but I ran this command in any case - no change

Otherwise... I'm not sure. Just so we can cross off some of the obvious troubleshooting steps, I would suggest that you look into the sections on restarting services, and common maintenance tasks on our troubleshooting page: 
  • Rebuild the nested set
  • Generate slugs
  • Clear the application cache
  • Restart services (Nginx, memcached, PHP-FPM)
  • Re-populate the search index
I've worked through all of the above without success ( except that I'm using apache rather than nginx)
My wget http://hracag.org.au/atom/index.php  returns a 500 error each time


Finally, you could also try creating a new Admin user from the command-line, and logging in with that account, to make sure the issue with not with that particular user. See: 
See if any of that helps - mostly, we are starting with the common solutions to reoccuring problems, to see if we can narrow down the cause. Let us know what you find.
I can't get into the login stage as index.php will not load


To unsubscribe from this group and stop receiving emails from it, send an email to ica-atom-user...@googlegroups.com.

To post to this group, send email to ica-ato...@googlegroups.com.
Visit this group at https://groups.google.com/group/ica-atom-users.

Dan Gillean

unread,
Jun 27, 2018, 4:35:54 PM6/27/18
to ICA-AtoM Users
Hi Tony, 

It is possible there is more than 1 php.ini file in your system. You might try running the checks to locate the file we suggest in this document?
We do define a PHP configuration pool during installation, so you might want to take a look at that and make sure everything is as it should be, and nothing is conflicting: 
Finally, we have documentation on AtoM configuration files here, though I don't think these would override your php.ini settings: 
As for the rest... based on what you are reporting, this is beginning to look like a web server configuration issue to me. Unfortunately, we don't really test with Apache or maintain full documentation for using it with AtoM, but I would start by looking there. 

I will see if our team has further ideas. 

Regards, 

Dan Gillean, MAS, MLIS
AtoM Program Manager
Artefactual Systems, Inc.
604-527-2056
@accesstomemory


Regards, 

--
You received this message because you are subscribed to the Google Groups "AtoM Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ica-atom-users+unsubscribe@googlegroups.com.
To post to this group, send email to ica-ato...@googlegroups.com.
Visit this group at https://groups.google.com/group/ica-atom-users.
--
You received this message because you are subscribed to the Google Groups "AtoM Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ica-atom-users+unsubscribe@googlegroups.com.
To post to this group, send email to ica-ato...@googlegroups.com.
Visit this group at https://groups.google.com/group/ica-atom-users.

--
You received this message because you are subscribed to the Google Groups "AtoM Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ica-atom-users+unsubscribe@googlegroups.com.
To post to this group, send email to ica-ato...@googlegroups.com.
Visit this group at https://groups.google.com/group/ica-atom-users.

mi...@artefactual.com

unread,
Jun 27, 2018, 5:05:55 PM6/27/18
to AtoM Users
Hi Tony,

If you put the following line above the line starting with "require_once" in the index.php file, what happens?

  print "TEST"; exit();

If, removing the above line, you put the following two lines above the line starting with "sfContext::createInstance", do you see errors?

  ini_set('display_errors', E_ALL);

  ini_set('error_reporting', E_ALL);


Be sure to remove these lines after testing.


Cheers,

Mike Cantelon

Artefactual Systems

Tony

unread,
Jun 28, 2018, 10:36:03 AM6/28/18
to ica-ato...@googlegroups.com
Thanks Dan,
My responses below
Tony



On 28/06/18 06:05, Dan Gillean wrote:
Hi Tony, 

It is possible there is more than 1 php.ini file in your system. You might try running the checks to locate the file we suggest in this document?
I can see three occurrences of php.ini

/etc/php5/apache2/php.ini
/etc/php5/cli/php.ini
/etc/php5/fpm/php.ini

In all cases log_errors = On

The file with a call to php_info() in the atom directory reports /etc/php5/apache2/php.ini is in use, and log_errors is off
A file with a call to php_info() in another unrelated directory reports /etc/php5/apache2/php.ini is in use, and log_errors is On



We do define a PHP configuration pool during installation, so you might want to take a look at that and make sure everything is as it should be, and nothing is conflicting: 
The configuration pooling seems to be Ubuntu 16.04 specific, whereas this is running under 14.04
Checked 14.04 configuration pooling is exactly as in the docs - cut and pasted
Checked Virtual Host documentation is also identical, except for the document root
To unsubscribe from this group and stop receiving emails from it, send an email to ica-atom-user...@googlegroups.com.

To post to this group, send email to ica-ato...@googlegroups.com.
Visit this group at https://groups.google.com/group/ica-atom-users.

Tony

unread,
Jun 28, 2018, 10:44:06 AM6/28/18
to ica-ato...@googlegroups.com
Thanks Mike,

    Test results are below

Tony




On 28/06/18 06:35, mi...@artefactual.com wrote:
Hi Tony,

If you put the following line above the line starting with "require_once" in the index.php file, what happens?

  print "TEST"; exit();
The browser displays TEST


If, removing the above line, you put the following two lines above the line starting with "sfContext::createInstance", do you see errors?

  ini_set('display_errors', E_ALL);

  ini_set('error_reporting', E_ALL);

Simply reports the 500 error as before


Be sure to remove these lines after testing.


Cheers,

Mike Cantelon

Artefactual Systems

--
You received this message because you are subscribed to the Google Groups "AtoM Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ica-atom-user...@googlegroups.com.
To post to this group, send email to ica-ato...@googlegroups.com.
Visit this group at https://groups.google.com/group/ica-atom-users.

mi...@artefactual.com

unread,
Jun 28, 2018, 2:32:22 PM6/28/18
to AtoM Users
Hi Tony,

So, to double check, after adding the line pertaining to error reporting, nothing ended up in Apache's error log?

Mike

mi...@artefactual.com

unread,
Jun 28, 2018, 2:38:52 PM6/28/18
to AtoM Users
Hi again, Tony,

Also, if you're running Apache with mod_proxy_fcgi, check for separate PHP ini files in one of the /etc directories relating to php5-fpm as, perhaps, one of those is effecting the display_errors setting.

Mike

Tony

unread,
Jun 29, 2018, 10:23:15 AM6/29/18
to ica-ato...@googlegroups.com
See responses below
Seems both paths, display and log error reporting are blocked
Tony




On 29/06/18 04:08, mi...@artefactual.com wrote:
Hi again, Tony,

Also, if you're running Apache with mod_proxy_fcgi, check for separate PHP ini files in one of the /etc directories relating to php5-fpm as, perhaps, one of those is effecting the display_errors setting.
I can see three occurrences of php.ini


/etc/php5/apache2/php.ini
/etc/php5/cli/php.ini
/etc/php5/fpm/php.ini

In all cases log_errors = On
Mike

On Thursday, June 28, 2018 at 11:32:22 AM UTC-7, mi...@artefactual.com wrote:
Hi Tony,

So, to double check, after adding the line pertaining to error reporting, nothing ended up in Apache's error log?
Yes, that's correct
Reply all
Reply to author
Forward
0 new messages