Difference between revisions of "UM error handling"
m |
|||
Line 3: | Line 3: | ||
== General description == | == General description == | ||
Archivematica anticipates that a number of different types of errors can occur during processing. Some of them will result in processing being halted and the transfer or SIP being moved to the failed directory in the file browser. For others, processing can continue: for example, a normalization failure is reported and the user is given the opportunity to continue processing the SIP. | Archivematica anticipates that a number of different types of errors can occur during processing. Some of them will result in processing being halted and the transfer or SIP being moved to the failed directory in the file browser. For others, processing can continue: for example, a normalization failure is reported and the user is given the opportunity to continue processing the SIP. | ||
+ | |||
+ | If you don't find an answer here or elsewhere in the user manual, please try searching the public [https://groups.google.com/forum/?fromgroups#!forum/archivematica user forum]. Someone may have had the same problem before and been offered a solution. If you do not find the answer there, feel free to ask us a question. The best questions to the list include as much information at possible about the error. This means offering us information about the system(s) you're using, the content of your transfer(s), and copying the task information (click on the cog on the same line as the micro-service job where the error occurred) and show command data output. | ||
== Dashboard error reporting == | == Dashboard error reporting == |
Revision as of 16:27, 11 October 2012
Main Page > Documentation > User manual > User manual 0.9 > Error handling
General description
Archivematica anticipates that a number of different types of errors can occur during processing. Some of them will result in processing being halted and the transfer or SIP being moved to the failed directory in the file browser. For others, processing can continue: for example, a normalization failure is reported and the user is given the opportunity to continue processing the SIP.
If you don't find an answer here or elsewhere in the user manual, please try searching the public user forum. Someone may have had the same problem before and been offered a solution. If you do not find the answer there, feel free to ask us a question. The best questions to the list include as much information at possible about the error. This means offering us information about the system(s) you're using, the content of your transfer(s), and copying the task information (click on the cog on the same line as the micro-service job where the error occurred) and show command data output.
Dashboard error reporting
- When a micro-service fails or encounters an error, the micro-service background turns from green to pink and a "failed" icon appears next to the transfer or SIP name (figure 1).
- Note that the transfer shown in figure 1 has been moved to the failed directory.
- Click the tasks icon (the gear icon on the right-hand side) to open up an error report (figure 2). These reports are generally standard and predictable for certain types of errors and are useful for trouble-shooting. Note that the failed file(s) will always appear at the top of the report.
Normalization errors
- The dashboard will report normalization errors when:
- Normalization is attempted but fails
- No normalization is attempted and the file is not in a recognized preservation or access format
- When normalization fails, the SIP continues processing until it reaches the normalization approval step. At this point, the user can click on the report icon next to the Actions drop-down menu to see a summary report of the normalization (figure 3).
- The report in figure 4 shows what has been normalized, what is already in an acceptable preservation and access format, and what has failed normalization or is not in a recognized preservation or access format. For example, the attempt to normalize the file LAND2.doc to an access format failed, while no attempts were made to normalize WFPC01.dwg, which is a format for which Archivematica has no normalization paths and which is not recognized as either an acceptable preservation or access format.
- The user may choose to continue processing the SIP despite any normalization errors. Future versions of Archivematica will also include the option to manually normalize files and continue SIP processing.
DIP upload error
- If the user accidentally enters a non-existing permalink, the upload DIP micro-service will fail, the DIP will be moved into the uploadedDIPs directory in the file borwser and an error report like the following will appear in the tasks report (figure 5):
- A future release of Archivematica will allow the user to continue to attempt to upload the DIP if a mistake was made entering the permalink.
Other common error behaviours
- Verify transfer compliance: if the user attempts to process a transfer that has not been structured with the logs, metadata and objects directories, the micro-service will fail, the transfer will be sent back to the transfer directory and the user will be able to restructure the transfer for compliance.
- Verify metadata directory checksums: if the checksums in the metadata directory cannot be verified (i.e. if a file is missing or corrupted) the micro-service will fail and the transfer will be moved in the failed directory.
- Scan for viruses: if a virus is found the micro-service will fail and the transfer will be moved in the failed directory.
- Characterize and extract metadata: if FITS processing fails, the micro-service will fail and the transfer will continue processing.
- Remove thumbs.db file: if Archivematica is unable to remove a thumbs.db file, the micro-service will fail and the SIP will continue processing.
- Normalize submission documentation to preservation format: if normalization fails, the micro-service will fail and the SIP will continue processing.
Rejecting a transfer or SIP
At any of the workflow approval points the user can choose to reject a transfer or SIP. This will move the transfer or SIP to the Rejected directory (accessible from the filebrowser) and will stop all processing on it. The transfer or SIP will still be listed in the dashboard, however. See Removing a transfer or SIP from the dashboard, below, to remove it from the dashboard.
Removing a transfer or SIP from the dashboard
To remove a transfer or SIP from the dashboard, click on the red "Remove" icon in the dashboard as shown in figure 8.