Atom 2.4.1 whitescreening

[carpo...@gmail.com]

Dear all, 

Our AtoM implementation running 2.4.1 has whitescreened on us, with the error message:

2019/03/11 18:26:14 [error] 1232#1232: *182 FastCGI sent in stderr: "PHP message: The "i18n" object does not exist in the current context" while reading response header from upstream, client: 46.229.168.152, server: _, request: "GET /index.php/informationobject/browse?creators=9744%2C1760&media=print&names=10048%2C9744&sf_culture=pt&showAdvanced=1&sort=relevance&topLod=0&view=table HTTP/1.1", upstream: "fastcgi://unix:/run/php7.0-fpm.atom.sock:", host: "archive.griffith.ox.ac.uk"

Two weeks ago, we had a similar problem with this, so took the decision to move the site to a new virtual server, running 16.04 Ubuntu LTS and setup as you'd expect and we're able to port everything over reasonably smoothly. Today this has come back, so I'm uncertain what is causing this. 

I see a lot of forum entries about 2.3.0 in terms of an install problem, but this is about a working operational site. 

Any ideas? 

Cheers

Richard Carpenter

IT Manager, Faculty of Oriental Studies, University of Oxford

[Dan Gillean]

Hi Richard, 

First, it looks like this search is being submitted in Portuguese. Have you added support for Portuguese via Admin > Settings > i18n languages, and re-indexed your site after making sure it is added there? See: 

• https://www.accesstomemory.org/docs/latest/user-manual/administer/settings/#add-remove-languages
  

Note - if you were not intending for this search to be submitted in Portuguese, and have no pt content, you may also want to take this opportunity to remove some languages. You should still re-index after. 

Second, I have found two previous instances in the user forum where this issue was resolved by adding more memory - in both cases, upping the available memory from 512 to 1024 MB (minimum) seems to have resolved the issue. 

Note that if your VM has 1024MB or more of memory available, it's still possible that it is not being used - you might want to review and adjust your memory_limit settings in your PHP configuration file. Please see the following page: 

• https://www.accesstomemory.org/docs/latest/admin-manual/installation/execution-limits/
  

If you change the memory allocation or your PHP execution limits, I would also recommend that you restart all services, clear the application cache, and re-index before retesting: 

• sudo systemctl restart php7.0-fpm
• sudo systemctl restart memcached
• php symfony cc
• php symfony search:populate

If none of this helps, can you please let me know: 

• The full version of AtoM - if you can't log in to check this in Admin > Settings, you can run the following task from the command-line: 
• php symfony tools:get-version
• The version of PHP you have installed
• The current amount of memory available in your VM and the memory_limit value in your php.ini file
• Any other information that you think will help us! 

Cheers, 

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-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.
To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/a0c6b908-d558-41de-b357-d75e148b4b0e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[carpo...@gmail.com]

Hi Dan, 

News for me about it indexing in Portuguese, i wasn't aware of that. I'll check with the staff tomorrow. Unless the staff who use it have added it, and i'd be surprised at that tbh. I didn't do this on new site install, and wasn't asked to either at any point. 

Sadly, those commands don't make a difference, the site still whitescreens for me when i go to the homepage. Is there anyother way to get into the back end of it?

As requested:

Version: 2.4.1 v156

PHP 7.0.33-0ubuntu0.16.04.2 (cli) ( NTS )

204MB of Ram

memory_limit set to -1

Cheers

Richard

[Dan Gillean]

Hi Richard, 

It's good to see that the database schema version is correct, as is your PHP version. Having the memory_limit set to -1 in your PHP configuration file should also be fine. However, if you only have 204MB of memory, that is likely the issue! I would look into seeing whether or not you can assign more memory to the VM?

Cheers, 

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

@accesstomemory

To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/299d0987-0bdf-49c9-bb8a-6e0cc7477cab%40googlegroups.com.

[carpo...@gmail.com]

Sorry Dan, 2048MB not 204MB, apologies. 

[carpo...@gmail.com]

To be clear what i meant by that, is that in the system right now is 2GB (2048MB) of RAM, not 204MB. I think the issues are langague related here. Is it possible to change this via the command line? 

[carpo...@gmail.com]

Further information out of error logs this morning:

2019/03/12 10:56:26 [error] 1232#1232: *28500 FastCGI sent in stderr: "PHP message: PHP Fatal error:  Uncaught Error: Call to undefined function render_title() in /usr/share/nginx/atom/apps/qubit/modules/staticpage/templates/homeSuccess.php:4

Stack trace:

#0 /usr/share/nginx/atom/cache/qubit/prod/config/config_core_compile.yml.php(3895): require()

#1 /usr/share/nginx/atom/cache/qubit/prod/config/config_core_compile.yml.php(3954): sfPHPView->renderFile('/usr/share/ngin...')

#2 /usr/share/nginx/atom/cache/qubit/prod/config/config_core_compile.yml.php(993): sfPHPView->render()

#3 /usr/share/nginx/atom/cache/qubit/prod/config/config_core_compile.yml.php(980): sfExecutionFilter->executeView('staticpage', 'home', 'Success', Array)

#4 /usr/share/nginx/atom/cache/qubit/prod/config/config_core_compile.yml.php(948): sfExecutionFilter->handleView(Object(sfFilterChain), Object(StaticPageHomeAction), 'Success')

#5 /usr/share/nginx/atom/cache/qubit/prod/config/config_core_compile.yml.php(1045): sfExecutionFilter->execute(Object(sfFilterChain))

#6 /usr/share/nginx/atom/lib/filter/QubitLimi" while reading response header from upstream, client: 163.1.185.80, server: _, request: "GET / HTTP/1.1", upstream: "fastcgi://unix:/run/php7.0-fpm.atom.sock:", host: "archive.griffith.ox.ac.uk"

And just to make absolutly sure, I just increased the RAM in the VM to 4096MB (4GB), Still whitescreens, no output at all. 

Cheers

Richard 

[Dan Gillean]

Hi Richard, 

Wow, ok - I thought that 204MB was an unlikely number! It's useful to know that 4GB of RAM hasn't resolved the issue - I think it's unlikely to be memory related in that case. For reference however, I will point out that in our docs, we've shared what Artefactual uses for a Standard hosted client deployment: 

• Processor: 2 vCPUs @ 2.3GHz
• Memory: 7GB
• Disk space (processing): 50GB at a minimum for AtoM’s core stack plus more storage would be required for supporting any substantial number of digital objects.

Going forward, I think it might be helpful to determine if this issue is data related or installation related. I would suggest that you make a backup of your database, and then we try purging the database to see if that grants you access. If the site works fine when there is no data loaded, then we know there's an issue in the DB - possibly some data corruption that's breaking something. If you still can't get the site running when the database has been purged, then there's an issue with the installation itself - filesystem permissions, missing dependencies, version conflicts, etc. Shall we try?

Backing up your data: 

Run all of the following from your AtoM root installation directory - generally, /usr/share/nginx/atom. The basic syntax for creating a sqldump of your database is: 

• mysqldump -u myusername -pMYPASSWORD mydbname > path/to/mybackupfile.sql
  

Where myusername and MYPASSWORD should be replaced with the SQL user credentials you used during installation - if you no longer recall, you can try looking in config/config.php. mydbname is the name of your database - I believe this should be atom if you have followed our recommended instructions. The path is where you want the backup to be created. So if my username and password are both root, my database name is atom, and i want to create my backup in the /tmp/ directory with a name of backup.sql, the command I would use is: 

• mysqldump -u root -proot atom > /tmp/backup.sql

I don't think it will be affected by the steps we are going to try, but if you want to back up your digital objects as well (if you have uploaded anything), you can make a copy of the uploads and downloads directories. For example: 

• cp -r /usr/share/nginx/atom/uploads /tmp

Purging the database: 

The following command will purge ALL data in your system - make sure you have backups before proceeding! We'll use the --demo option as well to temporarily create ourselves an admin account that uses de...@example.com as the login email, with a password of demo:

• php symfony tools:purge --demo

At this point, I recommend that you restart services, clear the cache, and repopulate the search index again. Now try to access your site - there won't be any data, but does the default homepage load?

If the purged site works

If the AtoM site now works, then we know the issue is in the database. Odds are good that some data corruption was introduced at some point in your use of AtoM. I would suggest that we reload your data, and then see if we can troubleshoot the data corruption. 

Before we reload the data, let's drop and recreate the database, to make sure we've gotten rid of any unnecessary tables and columns. Assuming again that root is your username and password, and that your database is named atom:  

• mysql -u root -proot -e 'drop database atom; create database atom character set utf8 collate utf8_unicode_ci;'

Now we can reload your data: 

• mysql -u root -proot atom < /tmp/backup.sql
  

Let's also run the upgrade task: 

• php symfony tools:upgrade-sql

And for good measure, clear the cache, restart services, and repopulate the index. 

In terms of checking for data corruption, start with the recommendations here: 

• https://www.accesstomemory.org/docs/2.5/admin-manual/maintenance/troubleshooting/#dealing-with-data-corruption
  

Let us know what you find. If none of those suggestions help I will check with our team - I believe that we've seen rare cases where language/culture values have become duplicated in the database. It's possible that something like this is happening for you.

If the purged site doesn't work

If the site didn't work after you purged the database and restarted services, then there is likely a deployment issue at play. I would first suggest that we try resetting all filesystem permissions. For AtoM to run properly, the www-data user needs the proper permissions for everything below the root installation directory. Try the following command: 

• sudo chown -R www-data:www-data /usr/share/nginx/atom
  

Once again, clear the cache, restart services, repopulate the index, and check if it works. 

If it's still not working? I would start checking the dependencies you have installed against our recommended installation documentation, and make sure you haven't missed something. For example, you can check on the PHP extensions you have installed, and make sure there isn't something missing with the following: 

• php -m

Compare that against the PHP extensions listed in our installation docs here. I would also suggest your review your PHP pool configuration and your Nginx server block. 

Let us know how it goes! 

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

@accesstomemory

To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/dda83485-e6bb-40ca-9572-ee44a4377d07%40googlegroups.com.

[carpo...@gmail.com]

Hi Dan, 

Thanks for your reply. I'm afraid the command php symfony tools:purge --demo failed with the error message:

The "i18n" object does not exist in the current context. 

Cheers

Richard

[Dan Gillean]

Hi Richard, 

Wow! Okay. I'm intrigued now. 

Let's try dropping and recreating the database first, and THEN running the purge task. 

If the purge task runs successfully after that, then we know for sure that the issue is with the data, and it's somehow interrupting the task execution. 

If the purge task doesn't work after we've dropped and recreated the database, then the issue is with the deployment. One of our developers thinks there is a high likelihood that the issue has to do with your cache configuration. 

I would suggest that you double-check that php apcu_bc is properly installed and configured, along with memcache and memcached. 

For apcu_bc, please note that we have manual installation instructions for it in the PHP section of the installation docs: 

• https://www.accesstomemory.org/docs/latest/admin-manual/installation/linux/ubuntu-xenial/#php
  

You can use php -m to check on other PHP extensions, and compare them against our installation instructions as well. 

For memache/d - there are in fact 2 different libraries with painfully similar names. We install php-memcache in the same PHP block linked above, and it's required. Memcached (with a d) is not required in AtoM but can be used - we include it in our Vagrant and Docker containers, for example. The following should output the versions for both: 

• dpkg -l | grep memcache

Feel free to share the output of this command. 

For checking if memcached is installed and running, you can always use the following: 

• Check version: memcached -V 
• Check status: sudo systemctl status memcached

You could always try installing it if it's missing and see if it helps: 

• sudo apt install memcached

Finally, I would doublecheck your PHP pool configuration. We created this in the installation instructions at /etc/php/7.0/fpm/pool.d/atom.conf - note the sections on APC and the Zend OpCache, and make sure your pool values are correct. 

If you make changes, remember to restart services and clear the application cache. 

Cheers, 

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

@accesstomemory

To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/d32e2237-fbba-4cdf-8174-82dba7bcff0e%40googlegroups.com.

[carpo...@gmail.com]

Hi Dan, 

It goes on. 

Same error message. Some other things to note: 

apcu_bc upon trying to run those instructions i get pecl/apcu_bc is already installed and is the same as the released version 1.0.5

ii  libmemcached11:amd64                 1.0.18-4.1ubuntu2                          amd64        C and C++ client library to the memcached server

ii  memcached                            1.4.25-2ubuntu1.4                          amd64        high-performance memory object caching system

ii  php-memcache                         3.0.9~20151130.fdbd46b-2                   amd64        memcache extension module for PHP5

memcached 1.4.25

● memcached.service - memcached daemon

   Loaded: loaded (/lib/systemd/system/memcached.service; enabled; vendor preset: enabled)

   Active: active (running) since Tue 2019-03-12 10:59:14 GMT; 7h ago

 Main PID: 1068 (memcached)

    Tasks: 6

   Memory: 908.0K

      CPU: 945ms

   CGroup: /system.slice/memcached.service

           └─1068 /usr/bin/memcached -m 64 -p 11211 -u memcache -l 127.0.0.1

Mar 12 10:59:14 orin-hammond systemd[1]: Started memcached daemon.

Now, the only thing i don't get is apcu_bc doesn't appear on the list of installs, on the php -m list which issues, could you check to see if looks correct or not from your point of view?

----

[PHP Modules]

apc

apcu

calendar

Core

ctype

curl

date

dom

exif

fileinfo

filter

ftp

gettext

hash

iconv

imagick

json

ldap

libxml

mbstring

mcrypt

memcache

mysqli

mysqlnd

openssl

pcntl

pcre

PDO

pdo_mysql

Phar

posix

readline

Reflection

session

shmop

SimpleXML

sockets

SPL

standard

sysvmsg

sysvsem

sysvshm

tokenizer

wddx

xml

xmlreader

xmlwriter

xsl

Zend OPcache

zip

zlib

[Zend Modules]

Zend OPcache

---

This server was created by me less than 10 days ago, to recover from the same error message on 2.4.0. I took the decision to upgrade to 2.4.1 at this time, because it needed to happen. 

Cheers

Richard

[Dan Gillean]

Hi Richard, 

I'm running out of ideas! Everything in the list you've posted matches what I'm seeing in my working Vagrant environment. 

If you're still getting the same error when trying to execute the purge task after dropping the database, then I still think there's something we're missing in the deployment. Did you double-check your PHP pool configuration file? In the meantime, I will ask our team to take a look and see if they have other suggestions. 

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

@accesstomemory

To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/20e94d20-ef6e-4b5e-b185-a84197884423%40googlegroups.com.

[raddao...@gmail.com]

Hi Richard,

This may be a permissions issue while reading the configuration files. I'd make sure that the AtoM folder and its contents are owned by the same user running the php-fpm AtoM poll and the web server (usually www-data). I'd also try to run the "php symfony ..." commands with that user.

Best regards.

[Karl Goetz]

Hi Richard,

Has anyone been making changes to the sites theme or other files?

If you run something like the following it may give some pointers (though you’ll need to filter out the cache files yourself)

`find /path/to/atom -mtime -3`

I’m also wondering if your atom logs include any details and if not, perhaps try running in debug mode (lock it down to your IP)

https://www.accesstomemory.org/en/docs/2.4/admin-manual/maintenance/debug/

karl.

--
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/a0c6b908-d558-41de-b357-d75e148b4b0e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

-- 

Karl Goetz

Mon, Tue, Wed, Technical Services Officer - eResearch

Wed, Thu, Fri Senior Library Officer (Library Systems)

University of Tasmania, Private Bag 25, Hobart 7001

University of Tasmania Electronic Communications Policy (December, 2014).
This email is confidential, and is for the intended recipient only. Access, disclosure, copying, distribution, or reliance on any of it by anyone outside the intended recipient organisation is prohibited and may be a criminal offence. Please delete if obtained in error and email confirmation to the sender. The views expressed in this email are not necessarily the views of the University of Tasmania, unless clearly intended otherwise.

[carpo...@gmail.com]

PHP pool is a straight copy and paste off the website, exactly as in the documentation. 

[atom]

; The user running the application

user = www-data

group = www-data

; Use UNIX sockets if Nginx and PHP-FPM are running in the same machine

listen = /run/php7.0-fpm.atom.sock

listen.owner = www-data

listen.group = www-data

listen.mode = 0600

; The following directives should be tweaked based in your hardware resources

pm = dynamic

pm.max_children = 30

pm.start_servers = 10

pm.min_spare_servers = 10

pm.max_spare_servers = 10

pm.max_requests = 200

chdir = /

; Some defaults for your PHP production environment

; A full list here: http://www.php.net/manual/en/ini.list.php

php_admin_value[expose_php] = off

php_admin_value[allow_url_fopen] = on

php_admin_value[memory_limit] = 512M

php_admin_value[max_execution_time] = 120

php_admin_value[post_max_size] = 72M

php_admin_value[upload_max_filesize] = 64M

php_admin_value[max_file_uploads] = 10

php_admin_value[cgi.fix_pathinfo] = 0

php_admin_value[display_errors] = off

php_admin_value[display_startup_errors] = off

php_admin_value[html_errors] = off

php_admin_value[session.use_only_cookies] = 0

; APC

php_admin_value[apc.enabled] = 1

php_admin_value[apc.shm_size] = 64M

php_admin_value[apc.num_files_hint] = 5000

php_admin_value[apc.stat] = 0

; Zend OPcache

php_admin_value[opcache.enable] = 1

php_admin_value[opcache.memory_consumption] = 192

php_admin_value[opcache.interned_strings_buffer] = 16

php_admin_value[opcache.max_accelerated_files] = 4000

php_admin_value[opcache.validate_timestamps] = 0

php_admin_value[opcache.fast_shutdown] = 1

; This is a good place to define some environment variables, e.g. use

; ATOM_DEBUG_IP to define a list of IP addresses with full access to the

; debug frontend or ATOM_READ_ONLY if you want AtoM to prevent

; authenticated users

env[ATOM_DEBUG_IP] = "10.10.10.10,127.0.0.1"

env[ATOM_READ_ONLY] = "off" 

However, i then made changes from off to on for display errors, display startup errors, and html errors and i get the following. 

Fatal error: Uncaught Error: Call to undefined function render_title() in /usr/share/nginx/atom/apps/qubit/modules/staticpage/templates/homeSuccess.php:4 Stack trace: #0 /usr/share/nginx/atom/cache/qubit/prod/config/config_core_compile.yml.php(3895): require() #1 /usr/share/nginx/atom/cache/qubit/prod/config/config_core_compile.yml.php(3954): sfPHPView->renderFile('/usr/share/ngin...') #2 /usr/share/nginx/atom/cache/qubit/prod/config/config_core_compile.yml.php(993): sfPHPView->render() #3 /usr/share/nginx/atom/cache/qubit/prod/config/config_core_compile.yml.php(980): sfExecutionFilter->executeView('staticpage', 'home', 'Success', Array) #4 /usr/share/nginx/atom/cache/qubit/prod/config/config_core_compile.yml.php(948): sfExecutionFilter->handleView(Object(sfFilterChain), Object(StaticPageHomeAction), 'Success') #5 /usr/share/nginx/atom/cache/qubit/prod/config/config_core_compile.yml.php(1045): sfExecutionFilter->execute(Object(sfFilterChain)) #6 /usr/share/nginx/atom/lib/filter/QubitLimitResults.class.php(34): sfFilterCha in /usr/share/nginx/atom/apps/qubit/modules/staticpage/templates/homeSuccess.php on line 4

Cheers

Richard

[carpo...@gmail.com]

Hi Jose, 

Tried with both www-data:www-data and <myacccount>:www-data as the permissions on the AtoM folder, no change. Rnning

sudo -u www-data php symfony tools:purge --demo

No change, same error message. 

Cheers

Richard

[carpo...@gmail.com]

No one has, the site files don't get changed at that level very often, and i can't see anything that hasn't been caused by those commands such as purge partially completing. 

Bottom line, I cannot fix this, so i'm going to have to deploy this to a new server today because we've been offline since Monday, despite everyones best efforts, but i'm honest unsure what this will achieve, it's already gone wrong twice now, the same way, in a same server. The only link was the weekend. Does AtoM run any scheduled tasks, especially in relation to i18n, on the weekend does anyone know?

On Tuesday, 12 March 2019 22:15:37 UTC, Karl Goetz wrote:

Hi Richard,

Has anyone been making changes to the sites theme or other files?

If you run something like the following it may give some pointers (though you’ll need to filter out the cache files yourself)

`find /path/to/atom -mtime -3`

I’m also wondering if your atom logs include any details and if not, perhaps try running in debug mode (lock it down to your IP)

https://www.accesstomemory.org/en/docs/2.4/admin-manual/maintenance/debug/

karl.

On 12 Mar 2019, at 5:35 am, carpo...@gmail.com wrote:

Dear all, 

Our AtoM implementation running 2.4.1 has whitescreened on us, with the error message:

2019/03/11 18:26:14 [error] 1232#1232: *182 FastCGI sent in stderr: "PHP message: The "i18n" object does not exist in the current context" while reading response header from upstream, client: 46.229.168.152, server: _, request: "GET /index.php/informationobject/browse?creators=9744%2C1760&media=print&names=10048%2C9744&sf_culture=pt&showAdvanced=1&sort=relevance&topLod=0&view=table HTTP/1.1", upstream: "fastcgi://unix:/run/php7.0-fpm.atom.sock:", host: "archive.griffith.ox.ac.uk"

Two weeks ago, we had a similar problem with this, so took the decision to move the site to a new virtual server, running 16.04 Ubuntu LTS and setup as you'd expect and we're able to port everything over reasonably smoothly. Today this has come back, so I'm uncertain what is causing this.

I see a lot of forum entries about 2.3.0 in terms of an install problem, but this is about a working operational site.

Any ideas? 

Cheers

Richard Carpenter

IT Manager, Faculty of Oriental Studies, University of Oxford

--
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-at...@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/a0c6b908-d558-41de-b357-d75e148b4b0e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

-- 

Karl Goetz

Mon, Tue, Wed, Technical Services Officer - eResearch

Wed, Thu, Fri Senior Library Officer (Library Systems)

University of Tasmania, Private Bag 25, Hobart 7001

[José Raddaoui]

Hi Richard,

The undefined function you're seeing is located in QubitHelper.php, which is loaded through apps/qubit/config/settings.yml. That settings file is created from "apps/qubit/config/settings.yml.tmpl" in the install process, so maybe the issue happened at that point. Do you have that settings.yml file in your AtoM folder? In any case, I'd suggest to trigger the web installer after clearing your installation:

- Recreate AtoM database.

- Make sure all AtoM content is owned by www-data (sudo chown -R www-data:www-data /usr/share/nginx/atom).

- Clear the application cache (sudo -u www-data php /usr/share/nginx/atom/symfony cc).

- Remove config file (/usr/share/nginx/atom/config/config.php) and the cache folder (/usr/share/nginx/atom/cache).

- Restart PHP-FPM.

- Open the site in the browser, it should redirect you to the installer.

I hope that makes it work.

Best regards.

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/b0f01a88-cb73-432b-abc8-c6bd806d11a6%40googlegroups.com.

[carpo...@gmail.com]

Interesting. Install fails on step three:

---

500 | Internal Server Error | sfException

The "i18n" object does not exist in the current context.

stack trace

• at ()
  in SF_ROOT_DIR/vendor/symfony/lib/util/sfContext.class.php line 500 ...
  
  497.   {
  498.     if (!$this->has($name))
  499.     {
  500.       throw new sfException(sprintf('The "%s" object does not exist in the current context.', $name));
  501.     }
  503.     return $this->factories[$name];
• at sfContext->get('i18n')
  in SF_ROOT_DIR/vendor/symfony/lib/util/sfContext.class.php line 616 ...
  
• at sfContext->__get('i18n')
  in SF_ROOT_DIR/plugins/sfInstallPlugin/lib/sfInstall.class.php line 484 ...
  
• at sfInstall::loadData()
  in SF_ROOT_DIR/plugins/sfInstallPlugin/modules/sfInstallPlugin/templates/loadDataSuccess.php line 5 ...
  
• at require('/usr/share/nginx/atom/plugins/sfInstallPlugin/modules/sfInstallPlugin/templates/loadDataSuccess.php')
  in SF_ROOT_DIR/cache/qubit/prod/config/config_core_compile.yml.php line 3895 ...
  
• at sfPHPView->renderFile('/usr/share/nginx/atom/plugins/sfInstallPlugin/modules/sfInstallPlugin/templates/loadDataSuccess.php')
  in SF_ROOT_DIR/cache/qubit/prod/config/config_core_compile.yml.php line 3954 ...
  
• at sfPHPView->render()
  in SF_ROOT_DIR/cache/qubit/prod/config/config_core_compile.yml.php line 993 ...
  
• at sfExecutionFilter->executeView('sfInstallPlugin', 'loadData', 'Success', array())
  in SF_ROOT_DIR/cache/qubit/prod/config/config_core_compile.yml.php line 980 ...
  
• at sfExecutionFilter->handleView(object('sfFilterChain'), object('sfInstallPluginLoadDataAction'), 'Success')
  in SF_ROOT_DIR/cache/qubit/prod/config/config_core_compile.yml.php line 948 ...
  
• at sfExecutionFilter->execute(object('sfFilterChain'))
  in SF_ROOT_DIR/cache/qubit/prod/config/config_core_compile.yml.php line 1045 ...
  
• at sfFilterChain->execute()
  in SF_ROOT_DIR/cache/qubit/prod/config/config_core_compile.yml.php line 1009 ...
  
• at sfRenderingFilter->execute(object('sfFilterChain'))
  in SF_ROOT_DIR/cache/qubit/prod/config/config_core_compile.yml.php line 1045 ...
  
• at sfFilterChain->execute()
  in SF_ROOT_DIR/plugins/sfHistoryPlugin/lib/sfHistoryPluginFilter.class.php line 18 ...
  
• at sfHistoryPluginFilter->execute(object('sfFilterChain'))
  in SF_ROOT_DIR/cache/qubit/prod/config/config_core_compile.yml.php line 1045 ...
  
• at sfFilterChain->execute()
  in SF_ROOT_DIR/lib/filter/QubitTransactionFilter.class.php line 48 ...
  
• at QubitTransactionFilter->execute(object('sfFilterChain'))
  in SF_ROOT_DIR/cache/qubit/prod/config/config_core_compile.yml.php line 1045 ...
  
• at sfFilterChain->execute()
  in SF_ROOT_DIR/cache/qubit/prod/config/config_core_compile.yml.php line 686 ...
  
• at sfController->forward('sfInstallPlugin', 'loadData')
  in SF_ROOT_DIR/cache/qubit/prod/config/config_core_compile.yml.php line 2392 ...
  
• at sfFrontWebController->dispatch()
  in SF_ROOT_DIR/vendor/symfony/lib/util/sfContext.class.php line 170 ...
  
• at sfContext->dispatch()
  in SF_ROOT_DIR/index.php line 6 ...
  

symfony settings ...

request ...

response ...

user ...

global vars ...

symfony v.1.4.20 - php 7.0.33-0ubuntu0.16.04.2
for help resolving this issue, please visit http://www.symfony-project.org/.

[José Raddaoui]

Hi again Ricardo,

Just found a couple of related threads:

- https://groups.google.com/forum/#!topic/ica-atom-users/Guab2J2rXtQ

- https://groups.google.com/forum/#!msg/ica-atom-users/m_JXLWB6jt0

And a Redmine ticket and code fix:

- https://projects.artefactual.com/issues/10648

- https://github.com/artefactual/atom/pull/509/files

Maybe you're using Mencached as cache engine and it's not being cleared in the code fix above. If that's the case, I'd try repeating the process from my previous update, flushing the Memcached data before restarting PHP-FPM.

Even if they don't look to be the same, I think both issues you're having (i18n and render_title) come from the same problem, which is loading the settings file where both, the i18n and the Qubit helpers are referenced. All I can think of is memory, permissions and/or cache and I think we tried all, so maybe a clean installation is the best option at this point.

Best regards.

To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/85f6f209-0ba5-4105-a186-d39aa10c1af1%40googlegroups.com.

[carpo...@gmail.com]

Hi Jose, 

Yeah, i've done that as well on a new virtual server. My concern is, this is what we did 10 days ago, worked for a little while, then fell over at the weekend exactly the same way. 

Cheers

Richard

[José Raddaoui]

Hi Ricardo,

As far as I know, there is nothing in AtoM that may cause the fell over by itself. Maybe there is something else interacting with AtoM, PHP or the cache engine in the virtual server. For example, a maintenance or a cron task. I'm really running out of ideas, sorry.

Best regards.

To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/38e0d69b-735e-4f90-8b5e-c503754fdab6%40googlegroups.com.

[carpo...@gmail.com]

That's okay, I don't have any ideas either. I can't see it being any unusual, this server is a sole deployment, dedicated for AtoM, nothing more.

[cultura...@gmail.com]

Hi mates, today I have faced exactly the same issue that Richard described, and I was able to solve it.

Environment

AtoM 2.4.1. - Dedicated instance

Ubuntu 16.04

Error log:

2019/11/21 14:50:50 [error] 2181#2181: *1396 FastCGI sent in stderr: "PHP message: PHP Fatal error:  Uncaught Error: Call to undefined function render_title() in /usr/share/nginx/atom/apps/qubit/modules/staticpage/templates/homeSuccess.$

Stack trace:
#0 /usr/share/nginx/atom/cache/qubit/prod/config/config_core_compile.yml.php(3895): require()
#1 /usr/share/nginx/atom/cache/qubit/prod/config/config_core_compile.yml.php(3954): sfPHPView->renderFile('/usr/share/ngin...')
#2 /usr/share/nginx/atom/cache/qubit/prod/config/config_core_compile.yml.php(993): sfPHPView->render()
#3 /usr/share/nginx/atom/cache/qubit/prod/config/config_core_compile.yml.php(980): sfExecutionFilter->executeView('staticpage', 'home', 'Success', Array)
#4 /usr/share/nginx/atom/cache/qubit/prod/config/config_core_compile.yml.php(948): sfExecutionFilter->handleView(Object(sfFilterChain), Object(StaticPageHomeAction), 'Success')
#5 /usr/share/nginx/atom/cache/qubit/prod/config/config_core_compile.yml.php(1045): sfExecutionFilter->execute(Object(sfFilterChain))

#6 /usr/share/nginx/atom/lib/filter/QubitLimi" while reading response header from upstream, client: 46.26.231.154, server: my.domain, request: "GET / HTTP/1.1", upstream: "fastcgi://unix:/run/php7.0-fpm.atom.sock:", host: "mydomain"
2019/11/21 14:51:07 [error] 2181#2181: *1300 FastCGI sent in stderr: "PHP message: The "i18n" object does not exist in the current context" while reading response header from upstream, client: IP, server: mydomain,  request: "GET /index.php/informationobject/browse?names=10102,10374,12924,6203,20381,9592,18578,9521,5919&sort=date&topLod=0&media=print HTTP/1.1", upstream: "fastcgi://unix:/run/php7.0-fpm.atom.sock:", host: "my.domain"

Searching for recent changes in the files as Karl pointed you get the list of files:

 find /usr/share/nginx/atom -mtime -3

output:

/usr/share/nginx/atom/config/propel.ini
/usr/share/nginx/atom/config/databases.yml
/usr/share/nginx/atom/log/qubit_worker.log
/usr/share/nginx/atom/apps/qubit/config/settings.yml

At the end of the results, I got 4 modified files, so I looked at size, permissions and modification hour:

ls -lha /usr/share/nginx/atom/config/propel.ini /usr/share/nginx/atom/config/databases.yml  /usr/share/nginx/atom/log/qubit_worker.log  /usr/share/nginx/atom/apps/qubit/config/settings.yml

In the output, 2  files that must have content were empty (suspicious), modified at the same time, and one them (setttings.yml) is related with the "default_culture" setting :

/usr/share/nginx/atom/config/propel.ini

/usr/share/nginx/atom/apps/qubit/config/settings.yml

Then I have recovered these 2 files from backup, apply permissions, clear cache and reload php-fpm:

$ sudo chown -R /usr/share/nginx/atom
$ cd /usr/share/nginx/atom

$ sudo php symfony cache:clear

$ sudo /etc/init.d/php7.0-fpm reload

That solves the problem for me, but what I can't figure what process is related with the content deletion of these 2 files (no cron task related). Maybe Dan and José can follow the issue, or explain which processes modify these files, since in other instances I saw that also were modified recently (daily?), but were not emptied.

 

Best regards from Spain,

Samuel Fernández

Cultural Hosting | Web Services for Cultural Heritage Organizations

culturalhosting.com

[lib-s...@unbc.ca]

Thank you Samuel! We just experienced this last night (AtoM 2.4.6, Ubuntu 18.04.6) and the fix was exactly what you described, replacing the empty files propel.ini and settings.yml, clearing the cache and restarting php7.2-fpm.

Very strange. We have two servers, Prod and Dev (which is a recent clone of Prod). Both servers had regular Ubuntu updates installed last night. After the reboots the Dev server was fine, but the Prod server had those empty files and the web interface wouldn't load. I copied those two files over from Dev, did the cache clear and reload, and everything appears ok on Prod.

David Pettitt

UNBC

[Paul Haynes]

Thank you for the article it just came in handy for the same fault presenting on our 2.6.4 (Upgrading to latest next month) instance of Atom. I had the same fault of a white screen and all tests showed services fine and php ok. Search for changed files found that the following 2 files changed but when i investigated them they were empty files and beside them in the same directory was files of same name but an TMP1 extension which contained the missing info. i restored these and a restart of service later and all was working again. 

/usr/share/nginx/atom/apps/qubit/config/settings.yml
/usr/share/nginx/atom/config/propel.ini

/usr/share/nginx/atom/apps/qubit/config/settings.yml.tmp1

/usr/share/nginx/atom/config/propel.ini.tmp1

Sharing to help others. 

Paul Haynes

[Dan Gillean]

Interesting, thanks so much for taking the time to update the thread with this information, Paul - and I'm glad that you were able to troubleshoot it! 

Cheers, 

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

@accesstomemory

he / him

--

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 view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/1cde9bb6-b61f-4976-9aff-765b813582f9n%40googlegroups.com.

[matthewb...@gmail.com]

Hi all,

I seem to be having the same problem. I am attaching a screenshot of the results I got when I did "find /usr/share/nginx/atom -mtime -3"

And when I did ls -lha on two of these files.

This all happened when my VPS migrated over to a new setup.

Unfortunately the back up was from after this point, and I dont know if I will be able to recover those files, because when I restore the backup to another instance of atom I have running, it is giving me the same white screen.

If anyone has any suggestions, I would be most greatful.

Matthew

[matthewb...@gmail.com]

ok, well I followed the instructions about copying the temporary files, and that worked. Useful to know this problem persists. I am using atom 2.6 .