As I described back in this article, I was getting segfault errors from eAccelerator.

I’m experiencing it on another, similarly-equipped GoDaddy VPS server. Same software versions, even, for Apache, PHP, eAccelerator, and OS, although this is not a old CMS Made Simple install.

Still, no good solutions out there, as far as I can google.

Here’s the clues I have found:

• The syntax function fun_name ($arg = array (blah)) is fatal.
• The order in which PHP extensions are loaded might matter.
• There are issues with files that get included or required multiple times via different paths.
• Software versions are just Too Old.

This is teh suckage.

Next thing I’ll try, when I have the time, is to upgrade the VPS to Fedora Core 6, and see if pushing those version numbers up a bit helps.

Windows update just told me it was installing a “Malicious Software Removal Tool.”

Gosh, I hope that the virtual hyphen is between the first two words, rather than the second.

*sigh*

So, it’s Saturday night, 10pm on a three-day Holiday Weekend. And another important server decides to have a fatal disk error.

How do they f*ing know?

It’s uncanny.

This is just another in a long series of similar failures. The power supply failed in my security-system a few years ago — hours before we were going to leave for a vacation. The previous time the security system crashed (due to unfortunate automatic software update) was — yup — the afternoon Elizabeth and I were leaving for a weekend cruise. And Elizabeth’s Mac had its hard drive fail the day I left for Bulgaria.

Of course, we all know why this is. There have been half a dozen other failures that happened during more mundane times, which evoked the standard rage/repair response. But that was par for the course, and soon forgotten.

So here I am. Saturday night … fixing machines. I should have been a ditch digger or something.

So, I’m working on an old RoR application, and was having a hard time getting it to work on my newer development machine.

The error dump was not at all clear:

C:\project\foo_bar_baz_quux>rake migrate --trace
(in C:/project/foo_bar_baz_quux)
** Invoke migrate (first_time)
** Invoke environment (first_time)
** Execute environment
** Execute migrate
rake aborted!
wrong number of arguments (1 for 0)
c:/ruby/lib/ruby/gems/1.8/gems/activerecord-1.13.2/lib/active_record/vendor/mysq
l.rb:551:in `initialize'
c:/ruby/lib/ruby/gems/1.8/gems/activerecord-1.13.2/lib/active_record/vendor/mysq
l.rb:551:in `new'
c:/ruby/lib/ruby/gems/1.8/gems/activerecord-1.13.2/lib/active_record/vendor/mysq
l.rb:551:in `scramble41'
c:/ruby/lib/ruby/gems/1.8/gems/activerecord-1.13.2/lib/active_record/vendor/mysq
l.rb:141:in `real_connect'
c:/ruby/lib/ruby/gems/1.8/gems/activerecord-1.13.2/lib/active_record/connection_
adapters/mysql_adapter.rb:316:in `connect'
c:/ruby/lib/ruby/gems/1.8/gems/activerecord-1.13.2/lib/active_record/connection_
adapters/mysql_adapter.rb:87:in `initialize'
c:/ruby/lib/ruby/gems/1.8/gems/activerecord-1.13.2/lib/active_record/connection_
adapters/mysql_adapter.rb:37:in `new'
c:/ruby/lib/ruby/gems/1.8/gems/activerecord-1.13.2/lib/active_record/connection_
adapters/mysql_adapter.rb:37:in `mysql_connection'
c:/ruby/lib/ruby/gems/1.8/gems/activerecord-1.13.2/lib/active_record/connection_
adapters/abstract/connection_specification.rb:145:in `send'
c:/ruby/lib/ruby/gems/1.8/gems/activerecord-1.13.2/lib/active_record/connection_
adapters/abstract/connection_specification.rb:145:in `connection_without_query_c
ache='
c:/ruby/lib/ruby/gems/1.8/gems/activerecord-1.13.2/lib/active_record/query_cache
.rb:54:in `connection='
c:/ruby/lib/ruby/gems/1.8/gems/activerecord-1.13.2/lib/active_record/connection_
adapters/abstract/connection_specification.rb:106:in `retrieve_connection'
c:/ruby/lib/ruby/gems/1.8/gems/activerecord-1.13.2/lib/active_record/connection_
adapters/abstract/connection_specification.rb:20:in `connection'
c:/ruby/lib/ruby/gems/1.8/gems/activerecord-1.13.2/lib/active_record/migration.r
b:178:in `migrate'
c:/ruby/lib/ruby/gems/1.8/gems/rails-1.0.0/lib/tasks/databases.rake:3
c:/ruby/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:399:in `call'
c:/ruby/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:399:in `execute'
c:/ruby/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:399:in `each'
c:/ruby/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:399:in `execute'
c:/ruby/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:369:in `invoke'
c:/ruby/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:362:in `synchronize'
c:/ruby/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:362:in `invoke'
c:/ruby/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:1935:in `run'
c:/ruby/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:1935:in `each'
c:/ruby/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:1935:in `run'
c:/ruby/lib/ruby/gems/1.8/gems/rake-0.7.2/bin/rake:7
c:/ruby/bin/rake.bat:20:in `load'
c:/ruby/bin/rake.bat:20


I went through a lot of work to use older versions of Rails, etc, but none of it worked. I didn’t find much out
there that helped, either, until I finally happened across this page.

Turns out it’s one of those pernicious password / old style password hash issues with MySQL. Simplest solution for now: use no database password on the dev box.

I have a number of very time consuming processes that get run by cron on various machines. Some of these processes would cause problems if they “overlapped” — e.g., a new one gets started before the old one is done.

Now, there are a lot of ways to make sure you’re unique if you’re a process, but often I don’t want to modify the source of the process to add that (for many packages, I’d rather not patch and merge and recompile every time a new version comes out). So I write a simple shell script to run the process; cron calls my shell script, and prevents the overlap.

This uses the magic of “pgrep” — unfortunately, different versions of pgrep have different flags, so the code I originally wrote (which used the “-c” flag, which counts the matching processes) didn’t port to most systems. It’s easy enough to pipe the output through a “wc -l”.

I did have to move the pgrep exec out of my if statement, though, since the comparison was going against the return code, not the output. Doh!

#!/bin/bash

RUNNING_PROCS = `pgrep -f longRunningProcess | wc -l`
if [ "$RUNNING_PROCS" -gt "0" ]
then
        echo `date` longRunningProcess still running. I\'ll let it finish. 
else
        echo `date` Starting longRunningProcess.
        /path/to/longRunningProcess -flags 
fi
echo "----------------------------"