SDP-884
Open
Revise SDP script log handling so checkpoint.log is a symlink (UNIX/Linux).
In several places in SDP script logging, there is a theme that the "simply
named" file name, i.e. the log file without a date/time stamp, is always
the most recent log. The 'checkpoint.log' is a prime example; there are
several others, such as sync_replica.log.
Having a consistent name to go to in order to see the latest log is
very useful and familiar to SDP users.
However, it also contributes to a problem where a log can get jumbled with
contents from multiple runs of a script, e.g. if a checkpoint script scheduled
to run daily runs for more than 24 hours, or if it is run concurrently by
multiple human admins or crontab interfering with human admins (regardless
of whether or not the given script supports concurrent operation).
This job calls for a change so that scripts start writing a new log file
immediately, and in early processing update the symlink to refer to the new
log file name.
Goals of this change:
* No more script log jumbling or log file overwriting/corruption due to
concurrent operation (or any other reason).
* No changes required to documentation or operational procedures. For example,
the familiar way of interacting with 'checkpoint.log' of doing a 'tail -f
checkpoint.log' just after starting one of the scripts that write to checkpoint.log
should work as expected. (That checkpoint.log file is written to by
daily_checkpoint.sh, live_checkpoint.sh, or rotate_journal.sh).
* In any cases where gzip of old logs occurs, make sure that does not delay
the start of core processing. For example, if the p4verify.log from an earlier
run is very large, it may take many minutes gzipping the old log before new
processing starts.
This would apply to the following:
* checkpoint.log
* sync_replica.log
* replica_cleanup.log
* request_checkpoint.log
* recreate_offline_db.log
* edge_shelf_replica.log
* upgrade.log
* sdp_upgrade.log
* journal_watch.log
* p4verify.log
* refresh_P4ROOT_from_offline_db.log
* purge_revisions.log
This would not apply to:
* p4login.log (which may need a "noise reduction change").
* monitor_metrics.log
This job is for the UNIX/Linux implementation; see SDP-885 for the Windows implementation.
In several places in SDP script logging, there is a theme that the "simply
named" file name, i.e. the log file without a date/time stamp, is always
the most recent log. The 'checkpoint.log' is a prime example; there are
several others, such as sync_replica.log.
Having a consistent name to go to in order to see the latest log is
very useful and familiar to SDP users.
However, it also contributes to a problem where a log can get jumbled with
contents from multiple runs of a script, e.g. if a checkpoint script scheduled
to run daily runs for more than 24 hours, or if it is run concurrently by
multiple human admins or crontab interfering with human admins (regardless
of whether or not the given script supports concurrent operation).
This job calls for a change so that scripts start writing a new log file
immediately, and in early processing update the symlink to refer to the new
log file name.
Goals of this change:
* No more script log jumbling or log file overwriting/corruption due to
concurrent operation (or any other reason).
* No changes required to documentation or operational procedures. For example,
the familiar way of interacting with 'checkpoint.log' of doing a 'tail -f
checkpoint.log' just after starting one of the scripts that write to checkpoint.log
should work as expected. (That checkpoint.log file is written to by
daily_checkpoint.sh, live_checkpoint.sh, or rotate_journal.sh).
* In any cases where gzip of old logs occurs, make sure that does not delay
the start of core processing. For example, if the p4verify.log from an earlier
run is very large, it may take many minutes gzipping the old log before new
processing starts.
This would apply to the following:
* checkpoint.log
* sync_replica.log
* replica_cleanup.log
* request_checkpoint.log
* recreate_offline_db.log
* edge_shelf_replica.log
* upgrade.log
* sdp_upgrade.log
* journal_watch.log
* p4verify.log
* refresh_P4ROOT_from_offline_db.log
* purge_revisions.log
This would not apply to:
* p4login.log (which may need a "noise reduction change").
* monitor_metrics.log
This job is for the UNIX/Linux implementation; see SDP-885 for the Windows implementation.
- Status
- Open
- Project
- perforce-software-sdp
- Severity
- B
- Reported By
- C. Thomas Tyler
- Reported Date
- 2 years ago
- Modified By
- C. Thomas Tyler
- Modified Date
- 2 years ago
- Owned By
- tom_tyler
- Component
- core-unix
- Type
- Feature
Log in to comment