PHP as Daemon

Posted on July 27th, 2006 in PHP by Russ

I had to write a php script that lived in an endless loop. However, once I started and backgrounded the process, I found that I couldn’t log out. Well, I could “log out” but the terminal session wouldn’t end until my processes quit. So I was stuck onto the server forever.

The solution to this would be to make the service detach from itself and then “run as a daemon.” I took about an hour and looked for examples on the web. The most popular ‘php as daemon’ script (on php.net) was a server that also did some port access and that sort of thing. All I needed was the “daemon”-ness and the pid of the child process. I’m sharing what I learned here- so you can start from my spot.


#!/usr/bin/php -q // adjust this for whereever your php is.
< ?php
$fh=fopen("/tmp/test.log", "a+"); // this is just opening the file to have something to do.

$notforked=pcntl_fork(); // this is the magic part.
$childpid=getmypid(); // this is the part that has the value for the pid file
if ($pid== -1) {
die('aiee!'); // something wrong happened, pcntl_fork didn't get run right. you might need to recompile php
}
elseif ( $notforked ) { // for some reason, we got back a non-zero value from the pcntl_fork() function.
}
else { // we were successfully forked.
while( true ) { // do this forever!
fwrite( $fh, mktime()." $childpid\n" ); // this is just a dorky example of something to do.
sleep(1); // if we don't sleep, the log file gets too big.
} // end of while
}// end of else

There’s some other things out there that can be done; you can handle signals (SIG_HUP, SIG_KILL) sent to your process and do some cleanup; but this is the basic “how do I break off to an eternal loop?” solution. I left “save the pid in a pidfile” as an exercise for the reader.

Ajax encourages sloppy programming

Posted on July 17th, 2006 in Javascript by Russ

When you use “regular old” HTML(link), you’re forced to present your page in just a few seconds. If it’s not there, the browser will time-out and you will wind up with a “500 Error,” your user might try again, but for the most part, you’ve lost your audience. However, when you use AJAX (Asynchronous Javascript And XML), you can lay out the main structure of your page, and then refresh each element individually; each element of the page then gets to time out seperately. Ajax proponents call this a ‘good thing’ because it helps the user experience your page as being interactive.

It can cause some Ajaxy sites to become slow, and having multiple Ajaxy sites (google calendar, flickr, etc) open in multiple windows can tax your bandwidth and your processor while you’re loading up all those pieces. I think this is a misuse of Ajax, because you’re not really helping the user, you’re clogging up their bandwidth. It also provides some bad examples of programming.

For instance, one programmer I know had to represent a series of fifty items. She created a webpage, and then called an ajax function and populated a list with all 50 items. When a user wanted to get some specific information from the web page, she added that info to the Ajax return, and then used the same ajax to query the database, using Javascript to parse it out differently for the more detailed view. This was easier on her, because she only had to write and test one set of ajax functions and two tests of Javascript functions, but it wound up being harder for the user, because the two queries (’give me a list of 50 items’ and ‘give me detailed info about this one item’ ) returned the same information:a lot of extraneous information was included in both result sets.

The problem is analogous to the reasons for the height and width attributes in image tags (in HTML(link)). If you don’t include the height and width attributes, then the page will continue to display the text; the browser will not know where to position the image. But if you do, then the browser can block off the position of the image, leaving no image actually shown. The page appears to load faster, because the user isn’t watching as parts of the page are laid out and moved around.

Witness, for example, gmail. Google’s search engine website is very fast; pages come back quickly after you push the submit button. But the gmail interface takes a long time to draw, while the Ajax works its magic ‘behind the screen’ and then shows the page.

I think that Ajax has its place in our web browsing world, and I appreciate all the hard work that goes into it- but some people are using it badly- and I think that Ajax is also good at covering those blemishes.

Godaddy Suckage?

Posted on July 4th, 2006 in PHP by Russ

Wow, the rumblings throughout the internet about the mighty GoDaddy. I use GoDaddy for my domain purchasing, I don’t use their hosting. I don’t even recommend their hosting; I’ve heard about enough problems with them and WordPress that my instincts steer me away from using them as a host. Apparently, not only are their customer support representatives perpetually in training, but their servers and their firewalls mangle some internet traffic badly enough to break some spam shielding software.

I’m all for people trying to make a buck. And I know how small the margin is on domain sales- I used to work for dotManiac, and because of the costs from their domain supplier, their domains are basically stuck at a specific price point. However, the ten pages of sales crap could really take the snap out of purchasing a domain.

So, between the hard core sales approach ( I really hate the beautiful image link “I’ll take one!” versus the text link “no, thanks.” ), the craptacular customer service and the firewall/server weirdnesses I’ve heard about (but can’t remember where it was), I’m going to have to start not-recommending goDaddy.com for domains too. Oh well.

Another person with rantings and ravings about how Go Daddy Sucks.