TL;DR Replace your init script with this one. It uses sudo to change to the RabbitMQ user before starting, stopping, and checking the status.
Here's a link that corroborates what I found: http://www.mentby.com/Group/rabbitmq-discuss/issues-on-rhel-62-with-rabbitmq-282.html
We're doing an upgrade of RabbitMQ here at Weebly. Moving from a CentOS 5 single node to CentOS 6 with DRBD and Pacemaker. Going from RabbitMQ 2.old-and-busted to 2.8.new-hotness. How hard could it be? Well a few things.
Alternatively, this post could be titled, "Mr. Smisek, your airline is in serious trouble."
I always raise an eyebrow whenever there's some sort of service disruption somewhere because someone says "the computers are down" or "the system won't let me do it." Chances are, they're just feeding you a line. The reality is that they don't know how to use the system (either lack of training or intelligence), or they just don't feel like working right then. Sure, systems do break, but not on the frequency that we hear about "the computers being down" constantly. We live in an age where someone sitting on their couch in Omaha can push a button and instantly trade billions of a foreign country's debt in milliseconds, but you're telling me that I can't pay for this taxi with a credit card because your reader is broken? Bullshit.
I pushed the updates up to Github; go and check it out:
I also changed the project name to reflect that it's no longer just a counter proxy. Yep, it now supports set (gauge) operations, too.
So just to recap, if you want to keep track of counters and gauges over UDP and get that data into OpenTSDB, check out the proxy. It's pretty basic, but it works decently well. Couchbase is used for shared state/data, so you can deploy a mess of these things and scale up as traffic requires.
We also now support dumping the counters out to a flat file. This is handy if you want to parse the data with something like OpenNMS for thresholding (we do).
Enjoy and please send me feedback!
Again, nerdy stuff follows. Click away now if you were looking for pics of naked chicks or something.
Like a lot of people buying new hardware these days, we've recently started to look into migrating from CentOS 5 to CentOS 6. New hardware really is the only reason we're looking to migrate. The new hardware isn't supported by CentOS 5 kickstart and rolling your own updates into a new kickstart image can be a PITA. So why not upgrade to the new stuff? How hard can it be?
WARNING: nerdy ops stuff below
Want to add low-latency counter support to your app and already run OpenTSDB? Don't like how OpenTSDB only takes updates via TCP? No, I don't either. I wrote a hacky proxy to accept UDP increment and decrement operations and send updates to OpenTSDB. It uses a persistent intermediary to store the values before updating OpenTSDB. It's up on the githubs. Have fun. RTFM.
In my last post, I ventured into the topic of monitoring individual SSD health using Intel's SMART stats, specifically, the Media_Wearout_Indicator. I contrasted this to someone's approach of monitoring for total number of bytes written. In the post, I also threw out the idea of monitoring these counters with smartd. Well, smartd wouldn't do what I wanted it to do (watch this counter and throw a fit if it dropped below a value). Sooooo, I did what any UNIX admin would do and replaced it with a shell script. We use OpenNMS and NRPE to trigger commandlets like this, so here's the script I wrote. It should work in Nagios, too. You'll probably have to customize the script to your liking, but it's straightforward and has some easy to tweak variables in the beginning. If you can't figure these variables out, time find a new line of work.
Full inline script after the jump (if you want to see what you can download).
A NOLA native just trying to get by. I live in San Francisco and work as a digital plumber for the joint that runs this thing. (Square/Weebly) Thoughts are mine, not my company's.