Mats Lindh

I’ve been playing around with RabbitMQ recently, but trying to find out what caused the above error included a trip through wireshark and an attempt to dig through the source code of php-amqplib. It seems that it’s (usually) caused by a permission problem: either the wrong username / password combination as reported by some on the wide internet, or by my own issue: the authenticated user didn’t have access to the vhost I tried to associate my connection with.

You can see the active permissions for a vhost path by using rabbitmqctl:

.. or you if you’ve installed the web management plugin for rabbitmq: select Virtual Hosts in the menu, then select the vhost you want to see permissions for.

You can give a user (all out) access to the vhost by using rabbitmqctl:

.. or by adding the permissions through the web management interface, where you can select the user and the permission regexes for the user/vhost combination.

After experimenting with deck.js yesterday for two presentations I had to give at a local networking meet, I decided to try to hack together a small extension for deck.js that makes any presentation an Ignite presentation. The concept is simply: 20 slides, 15 seconds for each slide – allowing you to only present the absolute minimum about a subject.

Using the extension is easy; simply download deck.ignite.js from my github repository and add a script tag that references the file after you’ve loaded the usual deck.js files (together with your other extensions):

You can also configure the delay used for each slide (Pecha Kucha presentations use 20 seconds) by setting the igniteDelay option when initializing deck:

You can read a more detailed description at the github project page.

This cryptic message may seem rather out of place, but it usually has a very simple explaination; the Gearman server address you provided does not have a Gearman server running. Your Gearman server is down, or the address is wrong.

The reason why this is the error you’ll see is that the call to set the exception option depends on the connection being up.

There is however another possibility – if your libgearman is newer than your gearmand (which will lead to libgearman attempting to set the exception option, while gearmand has no idea what an exception option is), you’ll also receive this error. The fix is to make sure that you use the same version of libgearman as the gearmand you’re running, either by downgrading the gearman module / library you’re using, or (more sensible) by upgrading gearmand to the same version. This was the cause of the issue mentioned in the comments.

If the log shows that the client connects, but then gets disconnected after sending a few REQ packets (or at another part of the exchange), the cause is probably that there is an incompability between the version of the server and the version of the client or worker. If the client or worker sends a request that the server can’t understand (if the client/worker uses a part of the protocol that wasn’t defined when the server was compiled), the server will disconnect the client or worker.

While running ./configure things may bail out with the message “cannot find the flags to link with boost thread”. This is cause by configure not being able to find the development version of the libboost-thread libraries on the current library path. If you’ve not built libboost from source, you probably need to install the -dev version of the libboost-thread package for your distribution.

For ubuntu this package is named libboost-thread-dev (you’ll find specific versions under names such as “libboost-thread1.46-dev”. Do apt-cache search libboost-thread to see which packages are available).

For Gentoo the package is named dev-libs/boost, so just emerge that one (thanks to J/#gearman).

While building gearman on our older RHEL4 servers, there was two issues that surfaced:

• The version of boost included in RHEL4 is too old (1.32) for gearman. I decided to download the new boost version (1.48.0 at the time of writing) and install it. Be sure to remove the old version with rpm -e boost-devel, so that you don’t get strange conflicts while attempting to build the benchmark tools:

  benchmark/blobslap_worker.cc:89: undefined reference to
  `boost::program_options::options_description::m_default_line_length'
  benchmark/benchmark_blobslap_worker-blobslap_worker.o(.text+0x1d9):
  benchmark/blobslap_worker.cc:89: undefined reference to
  `boost::program_options::options_description::m_default_line_length'
  

• Issues while trying to build the tests/ directory:

  tests/stress_worker.cc: In function `test_return_t worker_ramp_TEST(void*)':
  tests/stress_worker.cc:113: error: `pthread_timedjoin_np' was not declared in this scope
  tests/stress_worker.cc:113: warning: unused variable 'pthread_timedjoin_np'
  make: *** [tests/stress_worker.o] Error 1
  

  This can be solved by removing the whole section enclosed in the #ifdef _GNU_SOURCE
  section. Let the content in the #else-part in place. Removing this will not affect the usual (and any important parts of it) gearman distribution in any way.

The configure / make process of gearman needs a way to exclude the benchmark/ and tests/ parts of the project from being built.

One of the workstations at work had suddenly decided to not record any history of new sites visited .. and not to show any traces of old visits. After a bit of searching I found the recipe for How to fix a corrupt localstore which mentions a few of the same symptoms, in particular that the bookmark dialog won’t show up. Stopping Firefox and then renaming localstore.rdf did however not solve anything. Luckily I had remember that somewhere someone mentioned the places.sqlite database as containing information for the location field, so after stopping Firefox again, deleting the places.sqlite file and then restarting Firefox, everything went back to normal. Yet again Firefox knows where it has been!

A question that arised at the Freenode Solr IRC channel today was about _dist_:geodist() failing to include a field named _dist_ in the response – a field which would contain the return value from geodist(), which would be the distance from the source point to the destination document. The example from the wiki is:

&q=*:*&sfield=store&pt=45.15,-93.85&sort=geodist() asc&fl=_dist_:geodist()

The _dist_:geodist() in the fl= parameter adds a field named _dist_ with the returned contents from geodist() (the :-syntax creates a field name alias).

.. but why is it missing? Probably because using geodist() in the fl parameter is only supported on Solr 4.0 and later (which is currently only in trunk).

There’s a workaround on the wiki which you can use – but this will not allow you to score documents in any other way – the score returned will be the value of geodist() by using geodist() as the query:

q={!func}geodist()

A thread at /r/linux sought out to reveal all the magic ways of increasing productivity under Linux (or other *nix based OS-es), and as most people I thought that there wouldn’t be much news here.

But I was wrong. So very, very wrong.

1. disown – a way to disown a process, making it continue running in the background if you have to log out or close a long running session over ssh because you’re going somewhere, but want to keep the currently running process still running. If you’ve ever thought “why the fsck didn’t I run this under screen?”, then this trick is for you. This is a new future, and I’m proud to be a part of it.
2. CTRL+r in bash – allows you to search your bash history buffer. I’ve known about this, I’ve just never picked up the habit of actually using it. Will do that now.
3. ssh-copy-id – Appends your public key to the authorized_keys file at the destination computer.
4. man ascii – the manual page entry for ascii contains an ascii table, right there in your terminal.
5. xargs ‐‐max-procs and parallel – allows you to duplicate the functionality of xargs, but in parallel. Starts up all the processes at the same time, instead of starting them one by one.

Head over to the thread for other goodies such as a sudo alias for writing files when you’ve opened them without the correct permissions directly in vim.

When trying to find out why a particular ad campaign isn’t being delivered as you thought it should, the DFP documentation indicates that you should apply “google_debug” to the URL and a new window show pop up with the debug information. After digging through documentation and searching Google for a couple of hours without getting this to work, I finally found the relevant part of the DFP documentation.

Here’s the kicker: in the new, improved ad handler (gpt.js) you’ll have to append “google_console=1″ in your URL, then press CTRL+F10 to launch the debug console. No google_debug, no google_pubconsole, just google_console and CTRL+F10.

Hopefully this will help someone trying to find out by searching for relevant terms.