[
http://jira.dspace.org/jira/browse/DS-460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stuart Lewis updated DS-460:
----------------------------
Description:
A vanilla installation of DSpace is configured to log all activity to
[dspace]/log/dspace.log. Once the log file reaches 1mb, it renames itself to
dspace.log.1, and DSpace writes to a new dspace.log. Once this fills up, it
renames dspace.log.1 to dspace.log.2, renames dspace.log to dspace.log.1, and
starts a new dspace.log. This continues until dspace.log.500 is reached, upon
which any subsequent log rolling will cause dspace.log.500 to be deleted, and
the data is lost.
A downside of this is that backup systems will back up all log files every
night, as the filename for a given log file will change every time the logs
roll over. This can make it hard to recover old log files from a backup system.
The dspace.log file performs several functions:
- It provides log information useful for debugging technical problems
- It provides some level of access logging, showing who has access the system
- It is used to generate the DSpace statistics pages.
Many sites find that they fill up their 500mb of logs very quickly, often in a
matter of days or weeks in a busy site. After that, log files are lost, along
with the associated visitor statistics.
One solution is to increase the number of log files held, or increase their
size in log4j.properties.
An alternative and more robust solution would be to change the default
log4j.properties file to use the DailyRollingFileAppender which will instead
create date-stamped files, one per day. No log files will then be lost, and it
can be left to the system administrator to manage any deleting of log files.
Please add a comment to this issue, or use the 'Vote' button on the left, if
you would like this change to be made in the default DSpace out-the-box
configuration.
was:
A vanilla installation of DSpace is configured to log all activity to
[dspace]/log/dspace.log. Once the log file reaches 1mb, it renames itself to
dspace.log.1, and DSpace writes to a new dspace.log. Once this fills up, it
renames dspace.log.1 to dspace.log.2, renames dspace.log to dspace.log.1, and
starts a new dspace.log. This continues until dspace.log.500 is reached, upon
which any subsequent log rolling will cause dspace.log.500 to be deleted, and
the data is lost.
A downside of this is that backup systems will back up all log files every
night, as the filename for a given log file will change every time the logs
roll over. This can make it hard to recover old log files from a backup system.
The dspace.log file performs several functions:
- It provides log information useful for debugging technical problems
- It provides some level of access logging, showing who has access the system
- It is used to generate the DSpace statistics pages.
Many sites find that they fill up their 500mb of logs very quickly, often in a
matter of days or weeks in a busy site. After that, log files are lost, along
with the associated visitor statistics.
One solution is to increase the number of log files held, or increase their
size in log4j.properties.
An alternative and more robust solution would be to change the default
log4j.properties file to use the DailyRolloingFileAppender which will instead
create date-stamped files, one per day. No log files will then be lost, and it
can be left to the system administrator to manage any deleting of log files.
Please add a comment to this issue, or use the 'Vote' button on the left, if
you would like this change to be made in the default DSpace out-the-box
configuration.
> Change logging from RollingFileAppender to DailyRollingFileAppender
> -------------------------------------------------------------------
>
> Key: DS-460
> URL: http://jira.dspace.org/jira/browse/DS-460
> Project: DSpace 1.x
> Issue Type: Improvement
> Affects Versions: 1.5.0, 1.5.1, 1.5.2
> Reporter: Stuart Lewis
> Fix For: 1.6.0
>
>
> A vanilla installation of DSpace is configured to log all activity to
> [dspace]/log/dspace.log. Once the log file reaches 1mb, it renames itself to
> dspace.log.1, and DSpace writes to a new dspace.log. Once this fills up, it
> renames dspace.log.1 to dspace.log.2, renames dspace.log to dspace.log.1, and
> starts a new dspace.log. This continues until dspace.log.500 is reached, upon
> which any subsequent log rolling will cause dspace.log.500 to be deleted, and
> the data is lost.
> A downside of this is that backup systems will back up all log files every
> night, as the filename for a given log file will change every time the logs
> roll over. This can make it hard to recover old log files from a backup
> system.
> The dspace.log file performs several functions:
> - It provides log information useful for debugging technical problems
> - It provides some level of access logging, showing who has access the system
> - It is used to generate the DSpace statistics pages.
> Many sites find that they fill up their 500mb of logs very quickly, often in
> a matter of days or weeks in a busy site. After that, log files are lost,
> along with the associated visitor statistics.
> One solution is to increase the number of log files held, or increase their
> size in log4j.properties.
> An alternative and more robust solution would be to change the default
> log4j.properties file to use the DailyRollingFileAppender which will instead
> create date-stamped files, one per day. No log files will then be lost, and
> it can be left to the system administrator to manage any deleting of log
> files.
> Please add a comment to this issue, or use the 'Vote' button on the left, if
> you would like this change to be made in the default DSpace out-the-box
> configuration.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.dspace.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
Dspace-devel mailing list
Dspace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-devel
