I never got gmond and gmetad to start under launchctl as background daemons at boot, gmetad would die after a while and gmond would go nuts and respawn over and over until the machine was unusable. Running in the foreground works, this is how to set it up:
OSX 10.6.7, ganglia built in /opt/local from sources, rest of dependencies from Ports, daemons are in /opt/local/sbin, using OSX's Apache and PHP:
- Create two files in /Library/LaunchDaemons:
org.ganglia.gmetad.plist:
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN"
"http://www.apple.com/DTDs/PropertyList-1.0.dtd" >
<plist version='1.0'>
<dict>
<key>Label</key><string>org.ganglia.gmetad</string>
<key>ProgramArguments</key>
<array>
<string>/opt/local/sbin/gmetad</string>
<string>-d</string>
<string>1</string>
</array>
<key>RunAtLoad</key>
<true/>
</dict>
</plist>
org.ganglia.gmond.plist
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN"
"http://www.apple.com/DTDs/PropertyList-1.0.dtd" >
<plist version='1.0'>
<dict>
<key>Label</key><string>org.ganglia.gmond</string>
<key>ProgramArguments</key>
<array>
<string>/opt/local/sbin/gmond</string>
<string>-d</string>
<string>1</string>
</array>
<key>RunAtLoad</key> <true/>
</dict>
</plist>
- Incorporate them into launchctl's config:
sudo launchctl load -w /Library/LaunchDaemons/org.ganglia.gmond.plist
sudo launchctl load -w /Library/LaunchDaemons/org.ganglia.gmetad.plist
- Reboot to test. You should see
54 - org.ganglia.gmond
55 - org.ganglia.gmetad
in the output of "sudo launchctl list", the first column is the PID which you will see in the output of ps. Output goes into the system log.
[ view entry ] ( 900 views ) | permalink
I have a new iPhone 4 with Verizon service. It is, like, TOTALLY FREAKING AWESOME kind of. Since I had a Sprint HTC Evo in my previous job, I can compare firsthand.
Like the EVO, I first got only about 8 hrs standby time with location services ON and push ON. So:
1) Disable location services for all apps, or at least until the GPS arrow disappears from the top bar. Just like on all phones, GPS is a huge battery suck, and it won't work indoors anyway. Particularly, with Navigation - The Google Nav app that comes free with the Evo is considerably more awesome than anything available for the iPhone, but I could barely drive to the grocery store without using a car charger.
2) Disable Push if you can. Disabling Push globally still allowed my Exchange account to push (Push for Inbox is the default); I had to change that to "fetch" separately in the Push "Advanced" settings.
3) Disable Wifi if you can. Wifi isn't as big a battery suck as on the HTC Evo, though.
3) In spite of what the fanboys say, it's still possible for a badly behaved app to suck battery in the background. Try not to download dodgy apps, and worst case it's probably faster to just reboot your phone than kill off the apps one by one in the recently used view.
Once I found out it was Google Latitude background location updating that was sucking my battery dry in a day, I disabled that and now can get 2, maybe more, days battery life with location services ON, Wifi ON, and Bluetooth ON. I could *not* do that on the HTV Evo.
Would be nice to disable GPS entirely and rely on passive Wifi/Cell triangulation, but application whack-a-mole type tools, like on the Droid, don't seem to be necessary. Steve just wants you to quit fiddling, shut up, and enjoy your wonderful phone. So, compared to the Evo, I *do* like the iPhone 4 more.
[ view entry ] ( 1045 views ) | permalink
I had a job interview a couple days ago and the subject of Juniper EX series switches came up. Basically the interviewer had some EX devices gathering dust in a closet, having found them unreliable.
I'd say he was being a tad harsh, but then he needed a super-high-availability environment instead of a garden variety corporate LAN, and so his judgment was appropriate. In retrospect:
- Stacking devices into a virtual chassis is overrated. The EX virtual chassis is still buggy, and will probably be buggy forever. This is actually true of every manufacturer. Everyone's stacking is buggy.
- Instead, standalone boxes, with bog standard routing or trunking between them, will work just fine, and the relatively low cost of Juniper's 10Gb optics can make up for the lack of a 64Gb VC backplane interconnect.
- Juniper tech support is mediocre. They possess a gatekeeper mentality, and don't have much authority to fix your problem. Open a P1 support case, and tech support will try to convince you to reduce the priority. Stand firm - if you have a down building, open a P1 case and insist that asses be kicked until you have a point patch in hand to fix your bug.
- Avoid calling tech support by keeping your configs simple and your protocols standard.
[ view entry ] ( 1287 views ) | permalink
Some things that interest me right now:
- Cisco IOS to Juniper JunOS transitions - why put up with a 100Mbit network when you can get all-gigabit (and more) for the same price? Plus, learning JunOS is really easy.
- Enterprise email: Cyrus IMAP is OK, but if your users can't (or won't) set up Thunderbird themselves, insist on a web interface, and you aren't able to outsource to GMail, there is no better enterprise MTA+MUA I have found than Stalker Software's CommuniGate Pro. Forget about Exchange.
- Virtualization / consolidation / storage: These three, which are all part of the same thing, should make it easier, not harder, to roll out new services, but you need to drink the whole pitcher of virtualization kool-aid, not just a cup here and there, for it to be really game-changingly useful.
- Tape backup: It's OK for some situations, but this is what your Grandpa used for disaster recovery. See "virtualization kool-aid".
- 3rd Party Bloatware: If you just bought Remedy, Weblogic, eHealth, Netbackup, or some such 3rd party bloatware, and it doesn't work, then ask for your money back, and spend your refund check to hire *us* instead.
- Building out a data center? I am an infrastructure guru. Measure twice, cut once. Including the BTU calculations.
- Finally, monitor everything and anything with Nagios, MRTG, and/or Cacti. Why spend tens of thousands to install and license proprietary 3rd party monitoring software, then tens of thousands more for their consultants to come in and set it up for you, when you can do the same thing for only the cost of the expert assistance?
[ view entry ] ( 1055 views ) | permalink
We're just going to have to rip out Zmanda and start over. When we installed Zmanda 3.0.2 last year, it was buggy, and used Amanda 3.0.0 as the backend, which was even more not ready for prime anything. It was pretty much hopeless, especially on Solaris 10 (which we must have because of ZFS.) Even "amtapetype" didn't work. Zmanda thus set our splitsize to 100MB, so the backups span tens of thousands of files on each tape. Because of a tape positioning bug that Amanda and Solaris point at each other having to do with the "fsf after filemark" property, and that Amanda seems to need to assemble nearly an entire media's worth of data in /tmp, our backups are all useless. Well, we never really made it out of the testing phase and our primary backup is to save a few month's backups in ZFS snapshots.
I'm just going to have to rip it out and start all over. Because Zmanda uses a massively tweaked version of Amanda, I think I am just going to blow off Zmanda entirely. Sorry, guys, it was a nice idea, to commericialize Amanda, but Zmanda required just as much tweaking as Amanda, and required fairly comprehensive knowledge of Amanda internals to get working, so, now that I know Amanda better, why should I bother? Zmanda does have Windows, MySQL, etc clients, but we don't need 'em. It will back up to a cloud, but cloud backup isn't cheap. (Or I should say it has "recurring costs", which tend to not recur around here.)
[ view entry ] ( 1060 views ) | permalink
Search
