Re: precise syslogd configuration

[matthew sporleder <msporleder%gmail.com@localhost>]

2009/3/8 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.
>

As I read the original problem, we were trying to get rid of dhcpd
logs after two days.

The syslog protocol puts the limits on the facilities, etc.  I was
saying that the documentation in syslog.conf's man page has info on
using the daemon and user to put together blocks on configs.  If you
don't like the config syntax or the syslog protocol, then try a
different sysslog daemon.