nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

log file deletion

SethHickel

Is there a way to configure OD so that the logs in

\Interwoven\OpenDeployNG\log (src.Something.log and src.Something.log.mf) are deleted after a job completes?

Thank you.

Find more posts tagged with

Comments

Bhargav Coca

Is there a way to configure OD so that the logs in \Interwoven\OpenDeployNG\log (src.Something.log and src.Something.log.mf) are deleted after a job completes?

Thank you.

there are many options, out of which DNR is a good approach.

Thanks

SethHickel

DNR? Also, good to know there are many options. Could you suggest a few?

Thanks.

nipper

Deploy and Run.

Have a Perl script delete the files

Also, you can turn logging way down (configurable) which is my preferred method. Though log level and log size was not working as well as it shoudl in older copies of OD.

Adam Stoller

Is there a way to configure OD so that the logs in \Interwoven\OpenDeployNG\log (src.Something.log and src.Something.log.mf) are deleted after a job completes?

Thank you.

Strictly speaking - no, there is no way to configure that to happen and I think it's kind of foolish to do so.
As has been pointed out, you could have a DNR (on success only I would imagine) that uses what is hopefully a unique 'inst' value (that would be passed in with both the '-inst' and '-k' flags so it can be passed through to the DNR) to fairly easily find and delete the log files - but IMO it would be better to have a separate process that runs (nightly?) that goes through and deletes all OD log files that are older than X days so that you have at least 1 day's worth of log files to reference in case there are any questions about a deployment having happened.

Bhargav Coca

Strictly speaking - no, there is no way to configure that to happen and I think it's kind of foolish to do so.
As has been pointed out, you could have a DNR (on success only I would imagine) that uses what is hopefully a unique 'inst' value (that would be passed in with both the '-inst' and '-k' flags so it can be passed through to the DNR) to fairly easily find and delete the log files - but IMO it would be better to have a separate process that runs (nightly?) that goes through and deletes all OD log files that are older than X days so that you have at least 1 day's worth of log files to reference in case there are any questions about a deployment having happened.

I totally agree with Adam (Never Deny Him), also there is a draw back in here. Most of the companies do have their peak times like for a Companies organized events where people update their site like crazy, there will be tons of log files generated, during those days it would be good idea delete them periodically in very smaller chunks. Running the script would still keep most of the logfiles if the script is date based.

HTH

ISCBorisB

Strictly speaking - no, there is no way to configure that to happen and I think it's kind of foolish to do so.
As has been pointed out, you could have a DNR (on success only I would imagine) that uses what is hopefully a unique 'inst' value (that would be passed in with both the '-inst' and '-k' flags so it can be passed through to the DNR) to fairly easily find and delete the log files - but IMO it would be better to have a separate process that runs (nightly?) that goes through and deletes all OD log files that are older than X days so that you have at least 1 day's worth of log files to reference in case there are any questions about a deployment having happened.

DNR or not, arbitrary Deployment should not IMO have an ability to modify shared resources like Logs Collection.

The reason is simple - unpredictable starting time. It is far safer to prepare dedicated "Clean Up" script, interrogate
receiver activity and make balanced decision of what should go and what stays (at the very least, active Deployments
can not have their logs removed). Invocation mechanism of this stuff is secondary, it can be a DNR of dedicated Admin
Deployment, it can be scheduled, run ad-hoc by authorized personnel, etc

SethHickel

Thank you all: Great advice. I will heed it.