warning note: daemonology comes in two basic catagories
a) standard system type daemons
b) distributed networking solutions
AKA: OLTP systems, enterprise solutions, <YourBuzzHere>
for the first class syslog is ok enough - especially as gary
notes that one can modify the syslog.conf for an alternative
file to wonka to.... as generically is done by sendmail...
and other chatty kathy standard systems daemons.
The second space has other issues - since the second space includes
the daemonology used to monitor - well, the system.... which is the
space I am expecting most of the perlers will be writing in.
On Friday, May 17, 2002, at 01:16 , Gary Stainburn wrote:
[..]
> It gives a very good pre-defined way of controlling log entries. Using
> the
> syslog.conf you could filter out your messages to a seperate file, or
> even to a seperate machine.
the simple answer is:
Going to Syslog is like:
'well we can just send email'
- a good enough place to start the game
- but, well, SO EIGHTIES....
{ when constructing a syslog language once, I got to the bad hair
day where I proposed the interface that said
core=<yourCoreDumpHere>
because the silly code monkies needed to have the coffee break moment
that this was not the best of all solutions - although it would have
simplified getting their core files off - since well of course one
can have a network syslog host..... }
> Also, whay would stop you from just re-opening the STD[IN|OUT|ERR]
> handles to files in the root FS anyway? (I've not looked at the link
> provided
> and I've never done any daemon work, I'm just interrested)
The chdir to / in itself is not the problem - since that makes sure
that you start from a safe and general place - the question now
becomes - is this where you want to 'blow core' - when some impolite
and unforseen event occurs. { many *nix variants clean /tmp on reboot
so stuff that you write out there is not intended to survive crashes.
if you are in the POSIX world then go with
/opt/<ourPackageSpace>
/etc/opt/<ourPackageSpace>
/var/opt/<ourPackageSpace>
linux freaks disagree - but you can work around this.... but you
didn't ask about package installation solutions - which of course
is the better way to deliver your daemonology - which will of course
test for the requirements of the underlying perl modules - and install
them as needed...}
As for writing to / - WAY UNKOSHER - since for gooder practices only
root should be writing to / itself - and you really do not want to
open up all hell by running your daemon as root...
For the simpler cases - dumping things like $pidFile in temp has
the simple side effect that they go away on reboot - if that has
to happen... Since your general 'loging' will be by some other means,
then what winds up in /tmp as mydaemon.stdout and mydaemon.stderr
is really for catching those strange cases... Mondo Butch Daemons
will of course check to see if there are any issues in those files
prior to starting and will then truncate them as well...
if you look at the code, you will notice that I do reopen STD[OUT|ERR]
but there really is no point in reopening STDIN - as there is no
controlling terminal... see above for the 'control port' issue.
{ and folks wonder about the 'so why does drieux chatter on about
understanding how to implement an FD_SET in perl for socket management?'
well, because one of the sockets you want is your incoming message
queue from up stream daemons, one is your control port, one is for
your downstream daemon dialogs... }
Given that I expect that players will write daemons that use
other perl modules - since that is simpler than re-inventing the world.
We want to have STD[ERR|OUT] open so that any messages woofed out
of the modules that we use have some place to go - since those
module writers were generally expecting to use things like
die,croak,carp,confess -
print STDERR
print STDOUT
and we will be able to read their 'OH FREMONGE' messages.
As is
Proc::Daemon - and I DO ADVOCATE THIS!!!!
{ did I mention, that IF you are going to play in daemonology,
YES, download it from the CPAN - call out your dependence on it.....}
will leave STD[IN|OUT|ERR] open on /dev/null - hence you will
lose any die,croak,carp,confess messages - and your daemon
will die silently... your customers will ask:
Why did it die silently?
and your coders will ask
Why did it die silently?
where is the croak,carp, cluck, confess.....
and your management will beat on you with a stick, and your
professional peers will say
Neener,Neener,Neener
and you will spend many years in therapy because of that.
ciao
drieux
---
"But drieux, what is wrong with sending a message to
the syslog host that we can not contact the syslog host?"
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
