Technology Blog

So we had a customer call in today saying that order notification emails for their site were not going out.  They run on Magento 1.9.1 which has implemented a new email queue system for magento.  They receive about 100-1,000 orders a day, which can mean several thousand emails, since each order gets several emails post order (order confirmation, order update, order shipping/tracking number, follow up email).

So the first thing I did was place a test order on production.  I did not receive the email.  I looked in the /var/log/messages for the server and searched for my email address.  It was not in there.  I did notice other email’s in there, including the account creation email, which I almost dismissed to the client as the order email.  This email is not queued like the order emails so it immediately gets sent out.

So this was a bit scary, not seeing the email in the system /var/log/messages then I remembered about the queuing Magento has, and that it runs from cron.  I looked for a locked up cron by doing ps aux |grep cron but nothing came up.  It looked like no cron was locked.  I then remembered the client had AOE Scheduler installed.  I browsed to system->scheduler->list view.

In the table we had to select core_email_queue_send_all and click on the search button.  This limits the table view to this value.  I had something like 28 results found, but my view filter was set to show 25 at a time.  So I could not see the trouble 3 at the end.  I switched to show the view at 50 which showed me all of my results and I noticed the last item was a “RUNNING” process from several days ago.  There were a few “MISSED” processes before it.

I then selected the RUNNING row and selected “kill” from the actions window.  It then said it would kill on the next cron run.  This meant that I had to wait two minutes to check back.  I checked back and it was still there.  I then selected the row and clicked on “delete” from the action drop down and this immediately removed the row.  I waited two minutes and refreshed the page and it was now running.  I also started noticing through mailgun that the emails were sending but I didn’t get mine.  This is because the most emails magento will process in one cron is 100.  This means if you have 3,000 in queue, it will take 30 minutes to get them all out.

You may also need to do this with newsletter_send_all.

Delete the last commit

Deleting the last commit is the easiest case. Let’s say we have a remote mathnet with branch master that currently points to commit dd61ab32. We want to remove the top commit. Translated to git terminology, we want to force the master branch of the mathnet remote repository to the parent of dd61ab32:

$ git push mathnet +dd61ab32^:master
Where git interprets x^ as the parent of x and + as a forced non-fastforward push. If you have the master branch checked out locally, you can also do it in two simpler steps: First reset the branch to the parent of the current commit, then force-push it to the remote.

$ git reset HEAD^ --hard
$ git push mathnet -f

Originally taken from Christoph Copied here for reference.

For NYC Web Design check out the link.

I saw the check_mk added the ability to monitor the qmail mail queue, so I wanted to get that setup on a few plesk servers. The auto inventory wasn’t seeing the qmail and therefore wasn’t adding the check. It turns out that two things were wrong:

• I updated the check_mk agent on the plesk server, but didn’t update the check_mk software on the nagios host. I needed to install the latest version in BOTH places to get it working.
• Plesk uses its own paths, so we had to symlink /var/qmail/bin/qmail-qstat to /bin/qmail-qstat

ln -s /var/qmail/bin/qmail-qstat /bin/qmail-qstat

I spent way too much time figuring that out. Hopefully this post will help the next poor soul!

So today I needed a quick script to list all of the mysql databases on the system and compare that to the databases that were created inside of plesk. I wanted to print any databases that were created outside of plesk.

Why you might ask? It came to my attention that some of our system admins were creating databases manually through command line and setting up users that way when doing code deployments onto our shared plesk servers.

Whats wrong with that? Well if the database is outside of plesk, then plesk backup system, and plesk migration manager won’t know about the databases, nor the db users/passwords. This means if you are relying on plesk backup xml, or plesk migration manager for your server upgrades or disaster recovery, you’re going to have an issue with missing databases at some point!

The code is simple and is below. From memory it should work on plesk 8-11 and I have tested it on v10/11 myself.

Next to add to the list, is to set this up as a cron and email our general support queue if a new db is created outside of the plesk system.

To install / run, copy the below into a file called db_checker.php, then at a command line run “php db_checker.php”. You will need to be the root user to run this script.