Re: precise syslogd configuration

[Aleksej Saushev <asau%inbox.ru@localhost>]

  Hello!

matthew sporleder <msporleder%gmail.com@localhost> writes:

> On Sat, Mar 7, 2009 at 1:18 PM, Taylor R Campbell 
> <campbell%mumble.net@localhost> wrote:
>> (I am not subscribed to the list; please cc me in replies.)
>>
>> Am I going about this in the wrong way?  It seems suboptimal to
>> require such a carefully crafted configuration file, when I imagine it
>> is fairly common to want logs to be sent exclusively to a specific set
>> of destinations.  As it is, it's not obvious without reading the whole
>> file what destinations any particular log messages will be sent to.
>
> Did you read syslog.conf?  Especially the program and hostname specification.
>
> Anyway, a lot of daemons will give you the option to changing the
> syslog facility (LOCAL7, for example) to make this easier, but since
> dhcpd doesn't seem to, why don't you just start dhcpd with option -d
> and then redirect the output 2>/my/file
>
> That way you can set a cron job to cat /dev/null > /my/file or
> whatever else you want to do every two days.
>
> Either way should work.

Sorry? I don't understand, how your message addresses original problem.
Redirecting output to another file simply avoids it, using assumptions,
that everything happens on single host and daemon has write access to
file system (it may have none).

I am interested in original problem too, but I'm not interested in dirty
hacks like giving write access to file system (it isn't possible in my
setup).

Changing syslog facility doesn't help much, since you have only eight of
them and their names are not customizable. Sure, I can reuse LOG_LPR and
LOG_UUCP, given the fact that I don't have neither printers (it isn't cast
in stone though) nor UUCP.

Like original poster I find syslogd rather hard to setup and to maintain,
and this is bad, since it forces users to invent their own homebrew log
solutions instead of reusing system tool, only because the latter is hard
to configure and rather inflexible.

If the problem reduces to unclear documentation, fine, lets' fix manual,
if it is going beyond documentation, lets' split syslogd into backend
and frontend, so that users could have more clear understanding what's
going under the hood and could replace archaic parts (we're not in 80s
anyway) with their own. In my opinion, this frontend-backend split
aligns quite nice with clean code and embedded systems targets of the
project.


-- 
CKOPO BECHA...
   CKOPO CE3OH...