Something still cached somewhere

[Alan Bailward]

I have 2.6 installed and working great.  The archivists have been entering data, things going in fine.

Last night I was asked to change the theme from arDominion to arArchivesCanada (we are still customizing the look and feel and they wanted to see if the Archives Canada theme would be closer to what they want than customizing the default).  

I took a backup of nginx/atom and a dump of the atom database and copied them offsite.  I then changed the theme, which (barring any sort of programming errors) should not have affected anything (I assume).

I did a ‘php symphony cc’ after the change.

I get a call asking to change it back because a bunch of data has gone missing (authority records not linked to places and people - I think, I’m just the tech guy).

I change it back to the previous backup when everything was fine.  This is by moving the nginx/atom folder out of the way (atom.orig), copying the backup atom folder to where it was, and doing a MySQL -u atom atom < atom-backup.sql

The records are still not there / not linked.

Ok, I restore the night before’s backup and do the same thing.  Same result.  Nothing changes.

At this point I did the following:

 - php symphony cc

 - restart nginx

 - restart memcached

 - restart php-fpm 

 

Check again - no change.

Reboot the server in case something else didn’t get restarted.  No change still.

Unless there’s something I’m missing about what’s involved in restoring a site (other than the nginx/atom/* folder and the database) - there *must* be something cached still somewhere.  I’ve done the cc multiple times just in case as well as the restarting of those 3 services, but to no avail.  There *has* to be something I’m missing as to why it would not restore back to the state it was in 2 days before this (I assume innocuous change).  Hell, even if the software was buggy and it *did* wipe out record / links when changing a theme there’s no reason or it not to go back to how it was pre-backup!

Many thanks for any pointers.

[José Raddaoui]

Hi Alan,

Maybe the search index and the database got out of sync. or AtoM is not connecting properly to Elasticsearch after the file changes. What you're doing seems right to me, I'd just make sure to drop and recreate the database before the import, clear cache and restart the services as you did after the import (including the atom_worker service) and run the search populate task:

php symfony search:populate

Best regards,

Radda.

[Alan Bailward]

That didn't seem to do anything :(. 

The list of entries in the Archival Descriptions has now also changed - I'm not sure if the archives manager changed anything there though in an attempt to make more changes, or if the site simply f'd something else up on it's own. 

Do you know if there are any additional tasks that are running unattended that might be doing anything overnight?  My backup script is very simple (partially below) and yet sometimes things go wonky.  For example I did some menu naming changes about a week ago, and the day after some of them had reverted, things like that make me really wonder if there's something else going on here.

My backup script is about as simple as you can get though:

<defining a bunch of variables>

cd /

mysqldump atom | gzip -c > "$DEST_DIR/../../atom-database-backup-"`date +%F-%H-%M`.sql.gz

# Create the tarball

mkdir -p $DEST_DIR

tar cfz $DEST_DIR/$DEST_FILE $EXCLUDES $SOURCE_DIRS

<sends off an email with a link to the file>

<prunes old backups>

There's really nothing in there that should make *any* changes in the site, and yet obviously something is going on.  Any help in troubleshooting more would be appreciated.  The last thing I want to do is tell her *again* that she has to start from scratch inputting records in.  Confidence in the software (and me) is low already.

[José Raddaoui]

Hi again Alan,

AtoM doesn't have scheduled tasks by default. Did the archivists report any kind of error managing the site data? You may find something in the Nginx, PHP-FPM and atom-worker logs. There is also a troubleshooting page that may be helpful.

Best,

Radda.

[Dan Gillean]

Two additional tasks you could try running that often resolve strange errors - in this case I'm not sure they will help, but it won't hurt to try. 

• Rebuilding the nested set model - used for managing hierarchical relationships; can be responsible for records not showing up properly in the treeview
• Generating slugs - if a record is missing a slug, it will cause errors in the indexing process (and likely other errors) - I don't think this is the case here, but when the command is run with the default options, it will only generate slugs where they are missing, so any existing records shouldn't be negatively impacted. 

Both of the above tasks are described in this section of the Troubleshooting page, each with links to further information on the task options. 

Most often when records are missing, it is an indexing and/or caching issue. Restarting PHP-FPM and Memcached was a good thing to try - I suggest making sure you've run this again after re-populating the search index as Radda suggested if you hadn't already. 

Also: don't forget to remind your users to clear their browser caches, and/or test in a private or incognito browser window, where the browser cache is typically disabled by default. We often see reports of changes not showing up because the browser is caching an outdated copy of the data! 

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/ff71d886-0d2f-4ee0-b4a8-72849c80cb18n%40googlegroups.com.

[Alan Bailward]

Hi there - the issue has been (embarrassingly) found.  We thought that the items were public but weren't logged in while looking.  I'll just hide my head in shame and thank you for your help.

[Dan Gillean]

What a journey!

Alan, I'm just happy to hear that you're back on your feet, and that there wasn't some massive undiscovered bug or deployment issue crippling you. It's a learning experience! 

Thank you for updating the thread so we know. Best of luck going forward!

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

@accesstomemory

he / him

To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/d88f09d1-5017-471f-9fa7-fb67a07a29c3n%40googlegroups.com.