search

kamalasv / orthanc

Automatically exported from code.google.com/p/orthanc
GNU General Public License v3.0
0 stars 0 forks source link

Orthanc crashes after restoring from backup #27

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?
1. Install orthanc
2. Add some dicom files
3. Backup and restore directory

What is the expected output? What do you see instead?
I expected it to start normally, but instead see this...

W0116 20:26:22.829324  3380 main.cpp:677] Orthanc version: 0.8.5
W0116 20:26:22.829954  3380 OrthancInitialization.cpp:77] Using the 
configuration from: /etc/orthanc/orthanc.json
W0116 20:26:22.835293  3380 DicomServer.cpp:88] Loading the external DICOM 
dictionary "/usr/share/dcmtk/dicom.dic"
W0116 20:26:22.844895  3380 DicomServer.cpp:88] Loading the external DICOM 
dictionary "/usr/share/dcmtk/private.dic"
E0116 20:26:22.852388  3380 main.cpp:699] Uncaught exception, stopping now: 
[SQLite: Unable to open the database]
W0116 20:26:22.852675  3380 main.cpp:710] Orthanc has stopped

What version of the product are you using? On what operating system?
Latest on most recent ubuntu

Please provide any additional information below.
This occurred after testing backup and restore procedures on a live box.

The orthanc daemon was shut down, it's DICOMDIR backed up using s3fs to an s3 
bucket.
The s3 bucket was then mounted in the same location as the orthanc dicomdir.

I have verified that the index file is present in the same location with the 
same permissions and is byte for byte the same.  Additionally I have ran a file 
compare across the entire DICOMDIR for both the original and the backup, they 
are identical.

It is possible that there is a delay in opening the file introduced by s3fs, 
but I'm not sure where to look, or how to speed that up.

To my mind this just seems like orthanc is being stubborn about the index 
file,perhaps not giving it enough time.

Also is there a way to just recreate the orthanc index file, i.e. get it to 
re-index at start?  It seems to me that relying entirely on a single file from 
sqlite is begging for disaster.

Original issue reported on code.google.com by MaxPower...@gmail.com on 16 Jan 2015 at 8:42

GoogleCodeExporter commented 9 years ago 
The SQLite index of Orthanc should be stored directly on a local hard drive. It 
should not be stored on any cloud storage, as it is accessed and modified 
continuously: The varying delay coming from the cloud storage will impact 
SQLite, that contains evolved locking and timeout mechanisms:
https://www.sqlite.org/whentouse.html ("Situations Where Another RDBMS May Work 
Better")

Please also note that the corruption you observe might also come from s3fs or 
SQLite. No way to know...

This situation contrasts with the file storage, that can be put on the cloud 
using a plugin, because file storage is handled directly by Orthanc and not by 
SQLite.

In your case, if you really wish to use Orthanc in the Amazon cloud, you should 
put the SQLite index on the hard disk of the virtual machine (using the 
"IndexDirectory" option), and put the DICOM files on the s3fs file system 
(using the "StorageDirectory" option). You can then backup/restore the SQLite 
index to s3fs, provided Orthanc is properly stopped.

I tag the issue as "Won's fix" because cloud support for the SQLite index is 
clearly out of the scope of Orthanc. This might change with the support of 
PostgreSQL.

Original comment by s.jodo...@gmail.com on 23 Jan 2015 at 8:32