February 21st, 2001


I didn't get as much done as I wanted tonight, but my inbox is a little smaller, and I got a lot of the initial work done to the suggestion area.

Dormando's going to run the suggestion area.... I'd have given him FTP access to it already, but the FTP daemon isn't setup to notify another process to transfer the stuff to the other servers. Maybe NFS would be a good idea. On the other hand, I kinda like having the servers separated with different passwords, no trust between them, and separate copies of the files.... but maybe it's not worth it. I'm not sure. Thoughts? I was just going to have the FTP server make note in the database what files have been changed, and the other machines can poll that every minute and rsync what's changed... but then I'd need to add some trust between the servers, so what's the point of not using NFS? Hmm.

Other things....

Somebody needs to take over the text messaging stuff, because I don't have time to maintain it. Whitaker?

ASL thinks the memory is bad on lj-stan, so I'm going to go in tomorrow and run a memory test program they recommended on it. Hopefully it is bad and they ship us some more memory or something.... I want to get that machine up soon.

My friend said he wrote a patch awhile back for mod_backhand that fixed the multiple cookie bug, but couldn't release it due to his IP agreement. Now that he's out, though, he was free to reimplement it and release it, but he couldn't remember what he did or something. So no progress there. He may still figure it out, but I'm not hopeful.

Directory is still down, because the directory code indirectly crashes MySQL, because MySQL's table handler crashes when a table gets too large or too small too quickly. I can't make a repeatable test case, though. I suppose I could turn it back on, but then the site is god-awful slow while MySQL restarts after a crash, and if it restarts during a high traffic part of the day, then we're fucked for quite some time because all of MySQL's cache is invalidated, queries take forever, queries pile up, and then everybody starts hitting "reload" to make things load, piling up more slow queries for the already backlogged server to deal with.

Bad hardware, buggy mod_backhand, buggy database.... see a pattern here? This isn't fun. These aren't my damn problems, but I have to deal with them. Grrrrrrrrrrr.

I'm going to bed. Maybe I'll care more after I get some sleep.

FreeBSD question

How do I turn up the allowed ICMP rate?

I'm getting a lot of kernel messages like:

/kernel: icmp-response bandwidth limit 201/200 pps

But it seems mod_backhand uses icmp packets as one way to detect if a host is up, so at least on one interface, I want to disable or increase that rate, so mod_backhand doesn't mistake a host for being dead, just because the operating system wanted to prevent a DoS attack.

For all of you guys who thought you couldn't do anything...


If joined this community, and think there's nothing you can possibly do, you're probably very wrong :)

Here's an example: We're probably going to have a formal proposal process system set up soon. I know brad has a metric buttload of things to unload into the "DENIED" and "WORKING ON IT@#%@" category, but there might be stuff he forgot about, or would need more detail on.

So, in short, would any of you at least partially technically inclined people mind wading through the past posts/comments of lj_biz and lj_dev and compile a list of feature suggestions which were turned down, and why? (as well as links to the original posts/comments defining the suggestion and why it won't work). Also collect things which weren't turned down, in the same manner as with things that were turned down?

This looks like a gruntwork job, but just about everything is a gruntwork job, including writing annoying code features and debugging existing ones :)

Also, if it looks like the formal system is going to be delayed, I'd like to compile the results into a normal webpage.

Bye now.

Bad memory!

Hooray! The memory in lj-stan was in fact bad..... this is a relief. It's always better to know the problem. Now I'm waiting to hear back from aslab on what to do from here.