in reply to do i grok pidfiles?
-- Randal L. Schwartz, Perl hacker
Be sure to read my standard disclaimer if this is a reply.
|
|---|
| Replies are listed 'Best First'. | |
|---|---|
|
Re: •Re: do i grok pidfiles?
by zengargoyle (Deacon) on Feb 16, 2003 at 16:35 UTC | |
point taken and taken.
Pidfile showed promise, but i was trying to be fancy and get by with Pidfile::new returning a simple blessed scalar reference of the pidfilename. i couldn't quite pull it off gracefully =(. | [reply] [d/l] |
by jdporter (Paladin) on Feb 16, 2003 at 18:36 UTC | |
jdporter | [reply] |
by zengargoyle (Deacon) on Feb 16, 2003 at 20:36 UTC | |
knew i should have put a disclaimer in.... woe is it that i can't edit my root node. Warning: sorta rantish, but only because of the recent threads about Style and Changes in programming habbits. the original is a patched Proc::Pid::File, i barely dream of CPANing a module, much less with a lower-case-top-level-name. i'm just too lazy to think of a proper package name when i first need to make sure i'm not borking the whole concept. my private modules live in namespaces like 'W' and 'Q' because i use them often from one-liners and typing "-MWunderbar::Blat::Bonk -e '$wunderbar = Wunderbar::Blat::Bonk->new or die;..." quickly becomes a pain. i know people who log into a slowish web page with obnoxiously short inactivity timeouts *chuckle* to block an evil-doer when they could just do:
i usually have to do several ':%s/$scn/$long_descriptive_name/g' before cut-n-pasting a tested section of code here at the monastery. my daemons still being tested likewise live in /W because i'm to lazy to type /usr/site/app/version/bin/script check. when they're proven for a time and have the bells and whistles to make them usable by anyone but me, then they get big_long_descriptive_to_the_nth_degree_names, get put in rc.local, get their logs rotated, get rdisted ... now if i could just figure out a good way to document that one script that saves me an hour easily every time i use it and always DWIM, but nobody else can quite get the hang of it...
and i can't think of a good way to describe how each argument type is uniqely regexable and a configuration stack is updated when configuration things are given, and actions take place at the last possible moment using the top configuration stack entry when triggered by the next action thing given... but i still like that script more than the ones that give screens of --help information and get used by everybody. anyways, that was an early era script, and my early era daemons used a ugly hack for quick and dirty daemonization with frills.
worked ok, sorta ugly. the latest version of this uses Config::General for general configuration (overrideable with Getopt::Long command line options), Log::Log4perl (modifying logging while daemon is running is so cool.), Proc::Daemon (but i want to have the parent hang around long enough to verify the daemon is alive, so i'll have to re-wheel or maybe just stick another fork in there somewhere), and a patched Proc::PID::File. Proc::PID::File gets replaced. by something that DWIM with as short a name as i can manage (not as important when it's stable and you only have to type it once per script), and last but not least Pod2Usage for the docs. so, review 'package pidfile;' =~ s/pidfile/Some::Longer::Name/; so i can ask about 'package Proc::Daemon::Wrangler::ThingAMaBob;' =p | [reply] [d/l] [select] |