Converting "slashd" and Other Slash Daemons to "cron" Jobs
On the Slashcode Mailing List, Leo Grapendaal asked, "Where I ... have a problem {running Slashcode} is with the daemons. A lot providers, including
mine, do not allow you to run daemons of your own, so running slashd and
portald is out of the question.
Does anyone {know} if there is a way to run without these daemons? It'll
probably impact performance, but that's ok with me."
CTDATA has taken its copy of slashd and converted it into a cron job. If you are interested in how this is done, read on.
CTDATA is running an implementation of the Slash Engine that is derived from Slash 0.3. This is the version that preceded Slashcode 0.9x. So, our slashd implementation may be somewhat different from yours.
The idea behind our slashd implementation is that we can turn the script into a periodic batch command by removing the outermost loop and the sleep statement that serves to keep slashd running at all times. Once that was completed, we divided the housekeeping tasks that are done periodically into three separate groups, and added a parameter to the typical command line invocation of slashd.
- The stuff that needs to be done all the time, including the 0.3 subroutine called "freshenup" which checks for stories that need to be rendered, runs every two minutes and is invoked with slashd 2.
- Tasks that need to be done regularly otherwise they will be obviously out of sync with the story flow, like the story count related statistics for the Section and Topic slashboxes, are run every 10 minutes by a call to slashd 10.
- Tasks that need to be done once in a while, like regeneration of the Hall of Fame and Topics pages, and generation of our RSS files are done every 30 minutes. Of course, the command is slashd 30.
Even if the following code listing does not seem similar to the core functionality of your version of slashd, the code is written in a clear enough fashion to be indistinguishable from pseudocode.
#
# Start handling ARGV here.
#my ($op);
if ($#ARGV > -1)
{
$op = $ARGV[0];
}
else
{
$op = "2";
}slashdLog "Starting up Slashd with op = $op";
$dbh ||= sqlconnect();
if ($op eq "startup")
{
checkfortomorrow();
getsections();
gettopics();
newfooter();
}
elsif ($op eq "2")
{
freshenup();
}
elsif ($op eq "10")
{
getsections();
gettopics();
}
elsif ($op eq "30")
{
checkfortomorrow();
nukeBlockCache();
newfooter();
prog2file("$batchdir/hof.pl ssi=yes server=$ARGV[$#ARGV]",
"$basedir/hof.shtml");
prog2file("$batchdir/topics.pl all=on ssi=yes server=$ARGV[$#ARGV]",
"$basedir/topics.shtml");
system("$batchdir/syndication2.pl server=$ARGV[$#ARGV]");
slashdLog "RSS outbound syndication files written.";# system("$batchdir/calendar.pl");
# slashdLog "Calendar HTML created/updated.";}
$dbh->disconnect() if $dbh;
We added a second parameter to slashd rather quickly in order to accomodate multihoming. The second parameter passed is the equivalent of $ENV{SERVER_NAME} and simply allows Slash.pm to choose which database to access in the context of this invocation of slashd.
Anyone with any further questions should feel free to submit them as a comment to this story.