One of the neat things about the Drupal CMS is that it has a facility to schedule certain things to be run at regular intervals. For example: sending out subscription notifications or indexing posts for the search function. Those operations can take tens of seconds to complete, so you obviously don't want them executing in the middle of a page load.
The normal way to execute Drupal's crontabs is to load the script cron.php via the web interface. This is a terrible idea, since anyone with an Internet connection could cause your machine to run CPU intensive tasks at well, and bring the webserver to its knees.
An alternative way to run crontabs is with a third-party module called Poormanscron. It's a nice module, but the locking facility it has isn't so hot, and on more than one occasion I've had two cron runs execute in parallel, causing extra load on the machine. In especially bad (read: I/O bound) situations, multiple crontabs get "backed up" onto each other, and that creates huge load spikes and 60-second+ page loads until things calm down again.
There is yet a third way to run Drupal crontabs, and that's via the command line. It gives you maximum control over when and where crontabs run, and this is particularly important when you have multiple Drupal sites running. And I'm going to show you how to do it.
Step 1) Download Drush, the Drupal shell. It's a great little app for accessing your Drupal installation and performing common tasks from the command line. Install Drush (I usually put it in /usr/local/drush/, and make a symlink from /usr/local/bin/drush)
Step 2) Create a script in your home directory, and call it drupal-crontabs.sh. It should look something like this:
#!/bin/sh # # Our main directory for holding websites # ROOT=/var/www export DRUSH_OPTIONS="-q" #export DRUSH_OPTIONS="-v" # Debugging # # Errors are fatal # set -e cd $ROOT # # All of our drupal installations under $ROOT # SITES="furryconnectionnorth.com" SITES="$SITES saveardmorecoalition.org" SITES="$SITES claws-and-paws.com" SITES="$SITES sabanews.org" # # Loop through our sites to run crontabs on # for SITE in $SITES do cd $SITE # # Disable errors, since sometimes crontabs have issues. # set +e drush $DRUSH_OPTIONS cron set -e cd .. done
Be sure to season the $ROOT and $SITES variables to taste as per your specific installation.
If you run a chmod 755 on this script, you can execute it from the command line. However, you may run into file permission issues if the webserver is running as a different user than you (usually the case).
Step 3) Now you need to set up a crontab to run this script. My preferred way to do it is to create a file called /etc/cron.d/drupal-crontabs and place the following in it:
# # Run all of our crontabs for Drupal once an hour # MAILTO=root PATH=/usr/bin:/bin:/usr/local/bin 15 * * * * www-data /path/to/drupal-crontabs.sh
Make sure you are running these crontabs under the same user as your webserver.
That's it! If you want to see emailed notifications once an hour, just uncomment the line with the "-v" option for Drush. Otherwise, crontabs on all your sites will be run once an hour. Provided they do not take longer than hour to run, all of your search indexes and subscriptions will be kept up to date, and you will no longer have to worry about crontabs stomping over top of each other with Poormanscron. Enjoy!
Last weekend I headed down to Washington, D.C. to visit November and see the Cherry Blossom Festival.
I don't have much else to say about the festival, because it was a bunch of cherry trees, really. We walked around for a bit and I took a ton of pictures:
And here's the full slideshow:
Earlier today, I performed a major Drupal upgrade on another site that I run. Part of the upgrade involved me installing the Advanced Forum module to bring the forums a little more up to date with other sites that are out there.
Along the way, I learned something interesting: the Author Pane module does NOT display on blog posts.
It looked rather odd when comments on the blog posts had detailed user info, but the post itself did not. So I set out to fix that. I ended up commenting out the line
print $picture; in node.tpl.php and instead adding in these lines:
$account = user_load($node->uid); $template = "advf-author-pane"; $author_pane = theme('author_pane', $account, advanced_forum_path_to_images(), $template); print $author_pane;
The code is fairly straightforward. It loads user info on the author of the post, and the theme() function loads the author_pane template, passing in the user data.
Wow, it's been awhile since I've written here. Real life has had me very busy lately. I've done some neat things though, and I hope to post more about them soon.
The first neat thing I did recently was to roll out some badly needed updates for the user pages on anthrocon.org.
Before, I merely used the default pages that Drupal provided. The problem was that the pages looked a little... bland. Among other things, there were no icons for the various social networking services, and that just wouldn't do. So I read up on how to customize the user profile layout in Drupal and spent a couple of evenings writing some PHP code and making use of Drupal's theming functions.
Here are the old and the new pages side by side. Click on either to get a full page in a separate window.
|Old and busted:||New hotness:|
The upside of this effort is that when I'm ready to upgrade the Save Ardmore Coalition site to Drupal 6, I can pretty much just copy over my user templates on a wholesale basis, and save myself from having to redo all that work.
It was eerily quiet this morning. Many folks weren't going to work, and the roads were nearly empty. I took these pictures around 9 AM:
Lots of people weren't at the office today, either. I'm still not sure if we'll be back to normal tomorrow.
Looking back after this morning's stampede, I thought I'd share with folks how the webserver held up, since I know I am not the only geek out there. And, truth be told, I was a bit nervous myself, since I wasn't quite sure just how much traffic we would get and if the webserver would survive, or turn into a smoking crater.
Well, here's what we got:
The first hump is a manual backup I did last night. The second is the automatic backup that runs every morning, where the database and files are rsynced to a machine at another data center. The third hump at 9 AM was when we opened hotel reservations. 1.4 Megabits/sec doesn't look too bad, until you look at:
The 336 simultaneous connections a second was far more interesting. That's about 16 times the normal number of connections to the webserver.
So, what were the effects? Let's look at MySQL first:
Since folks keep asking me what conventions I work and whether I'm a staff member at such and such convention, I figured it was about time I made a list.
Back in late December, I purchased a brand new D3000 camera from Ritz Camera here in Ardmore. It was my first SLR camera, and I enjoyed taking pictures with it, both at Christmas with the family, and New Years at Wuffmeet.
Unfortunately, shortly after New Years, my camera experienced a case of "infant mortality", as we call it in the tech industry. Upon turning it on, it displayed the dreaded "lens not attached" error, which seems to be the Nikon equivalent of the Blue Screen Of Death. I tried Googling for solutions (are the contacts clean? They looked clean to me!) but came up empty handed.
My first step was to call the store, but that didn't help. They suggested I send the camera into Nikon, which struck both myself and other folks on Facebook as a bit odd since it was within 30 days. So the next thing I did was to send a note to their customer service (firstname.lastname@example.org) and ask for help. That resulted in my email being forwarded to Adam, store manager at Ardmore's store, who gave me a call the next day to discuss the issue. We both agreed that the camera was defective, and he kindly offered to swap that one out for a second camera.
I stopped by the following Saturday morning, and we spent about 20 minutes going through our respective boxes (ALWAYS save boxes when you buy electronic items) and only swapping the camera and lens, and exterior box. (it had the serial number on it) Other than the initial communication issues, the whole exchange process went pretty well, and I was rather pleased with how Ritz Camera handled the situation. Yeah, I think I'll keep buying camera-related items from them.
Other than that, most of my shots were of a few dogs that joined us:
Don't get me wrong, I don't have any sort of personality trait that gets dogs to pay attention to me. I just made sure to have a cookie in my hand. You'd be amazed at how well that gets the attention of dogs!
Earlier today, I returned home from my parents' place in Allentown. Normally, I take the train up, and they drive me back.
That turned out to be not such a hot idea today, as evidenced by this picture:
Yes, I was standing in the middle of the road when I took that picture. Seems that there was an accident south of Lansdale which took out both lanes, and traffic could only get by on the shoulder, leading to a 10+ mile traffic jam.
Could have been worse, I suppose. The weather was nice, and we didn't have any road rage to deal with. The total wait was only about an hour.
This was the view looking forward:
The read of the pics are at http://www.flickr.com/photos/dmuth/sets/72157623081612348/.