[arch-dev-public] [signoff] dcron 4.3

[Paul Mattal]

On 01/12/2010 04:16 PM, Eric Bélanger wrote:
> On Tue, Jan 12, 2010 at 4:04 PM, Aaron Griffin<aaronmgriffin at gmail.com>  wrote:
>> On Tue, Jan 12, 2010 at 3:01 PM, Eric Bélanger<snowmaniscool at gmail.com>  wrote:
>>> On Tue, Jan 12, 2010 at 8:28 AM, Paul Mattal<paul at mattal.com>  wrote:
>>>> In testing 4.2, we've encountered some minor issues, and I have now put
>>>> version 4.3 in testing.
>>>>
>>>> I'd like to get 2 signoffs per arch for this large update.
>>>>
>>>> Here's the changelog since 4.2:
>>>>
>>>> v4.3  11-Jan-2010
>>>>
>>>>   * Internal refactoring to make buffer overflow checks
>>>>     clearer and portability issues more explicit.
>>>>
>>>>   * Made file argument to -L mandatory; optional args to
>>>>     getopt needs GNU extensions.
>>>>
>>>>   * Makefile tweaks. Added CRONTAB_GROUP for `make install`.
>>>>     Renamed TIMESTAMPS ->  CRONSTAMPS.
>>>>
>>>> Additionally, I took Eric's advice to follow the norm not to put
>>>> /etc/rc.d/crond in the backups array.
>>>>
>>>> Enjoy!
>>>>
>>>> - P
>>>>
>>>
>>> Another possible issue I found out. I am not an expert on system
>>> logging so I might be incorrect.
>>>
>>> As the dcron logging is now managed by syslog-ng, it shouldn't provide
>>> a /etc/logrotate.d/crond.  Instead, we should release a new syslog-ng
>>> package with /var/log/crond.log added to the list of logfiles being
>>> taken care of in its /etc/logrotate.d/syslog-ng. We could add, at the
>>> same time, the other logfiles created by syslog-ng but currently
>>> ignored in the log rotation:
>>>
>>> /var/log/lpr.log
>>> /var/log/uucp.log
>>> /var/log/news.log
>>> /var/log/ppp.log
>>> /var/log/debug.log
>>> /var/log/acpid.log
>>>
>>> Am I missing something? Any objections, comments?
>>
>> Actually, that sounds backwards to me. If cron isn't installed, we
>> have no log file. It makes sense to me - if pkgA adds more log files
>> that get big, it should also provide its own logrotate file.
>>
>
> I guess it depends how you see it.  The way I see it is that it's
> syslog-ng who creates the file and appends to it so it should be
> responsible for the rotation as well.  Plus, we use the missingok
> option so if the file is missing, it just skips it whithout even
> issuing an error message.  So no harm is done.

I can see both sides of this, but in essence, it seems like it's 
syslog-ng which ultimately decides the filename-- if syslog-ng.conf 
is changed to log cron output to another file, it's syslog-ng that 
decides where they go. So I think I agree with Eric that syslog-ng 
should be responsible for the rotating the files it determines 
should exist in its default configuration.

I'll wait a while to hear from others before doing anything directly 
to address this.

- P