Bug #770
Greyhole can get into recursive loop in trying to process a file after "Network problem"
0%
Description
When "cutting/pasting" a load of files from Server2008 to Amahi, I had 1 file "fail" with a "Network Error". The message in windows was:
"There is a problem accessing \\HDA\ShareName
Make sure you are connected and try again"
Regardless of how many times I click on "Try again", it simply won't work, and I'm forced to "Skip" the file. All subsequent file moves seem to work, so I can't see why there's a network problem!
Anyway, after this occurs, I then copy the "skipped" file on its own at the end when all other files have been done. Since I have sticky_files set for this share with stick_into entries for drive1 and drive2, when the problematic file is finally copied over to Amahi, Greyhole seems to copy the file OK onto drive2, and then onto drive1, but then it seems to try and process another copy of the file on drive1 also. It keeps doing this recursively, and in the end gives up (a message in greyhole.log, at this point, says the file "is locked by another process. Will wait until it's unlocked to work on it", but the file seems to have disappeared anyway!
Now, the file that Greyhole keeps trying to process is the problematic file, but with an additional part added onto the extension. At one point, I noticed this added to the entention:
.8e339.RoTiSa
Then, the extension changed to just have this added:
.8e339
Then, it changed again to this:
.8e339.LUF82s
None of these extensions seem to appear in the Greyhole log (just the original file, with its .dvrms extension).
I'm guessing that Greyhole adds a temporary extension to any file whilst it is copying it over, and because it gets confused somehow, it's added 2 temporary extensions.
This has occured more than once with different files.
History
#1 Updated by dinomic about 10 years ago
- File 07_-_2_The_Turkish_Grand_Prix_-_Race_Day_LIVE_BBC_One_07_06_2009_12_09_42.dvr-ms___ISSUES_Report1228 added
Attached is a snippet of the info logged in greyhole.log for the file in question
#2 Updated by sidelight almost 10 years ago
I see this issue too.
Mar 04 17:18:19 6 daemon: Greyhole (version 0.9.1) daemon started.
Mar 04 17:18:19 7 daemon: Loading graveyard backup directories...
.
.
.
Mar 04 17:18:19 7 parse_logs: Parsing Samba logs...
Mar 04 17:18:19 7 parse_logs: Done parsing.
Mar 04 17:18:19 7 read_smb_spool: Processing Samba spool...
Mar 04 17:18:19 7 simplify_tasks: Simplifying pending tasks.
Mar 04 17:18:19 7 write: Now working on task ID 1004939: write Virtual Machines/training/ISO_IDM4/FCS/Identity_Manager_4.0_Windows_Enterprise.iso
Mar 04 17:18:19 6 write: File created: Virtual Machines/training/FCS/Windows_Enterprise.iso - 3.10GB
Mar 04 17:18:19 7 write: Loading tombstones for Virtual Machines/training/FCS/Windows_Enterprise.iso... Got 0 tombstones.
Mar 04 17:18:28 7 write: Skipping open file (lock) check.
Mar 04 17:18:29 7 write: Drives with available space: /var/hda/files/drives/drive3/gh (254GB avail) - /var/hda/files/drives/drive2/gh (253GB avail) - /var/hda/files/drives/drive4/gh (252GB avail) - /var/hda/files/drives/drive1/gh (244GB avail)
Mar 04 17:18:29 7 write: Saving 1 tombstones for Virtual Machines/training/FCS/Windows_Enterprise.iso
Mar 04 17:18:29 7 write: Saving tombstones in /var/hda/files/drives/drive3/gh/.gh_graveyard/Virtual Machines/training/FCS/Windows_Enterprise.iso
Mar 04 17:18:29 7 write: Saving tombstones (backup) in /var/hda/files/drives/drive1/gh/.gh_graveyard_backup/Virtual Machines/training/FCS/Windows_Enterprise.iso
It looks suspiciously like greyhole is correctly identifying that the file is locked but then tries to do the move anyway. at this point windows reports network problems. I've tried wired and wireless and from multiple clients with the same result.
#3 Updated by gboudreau almost 10 years ago
"Skipping open file (lock) check."
This indicates that Greyhole skipped the lock check, effectively working on locked files, which is a big no-no.
This is a new config option I added to play with, which I guess Amahi uses the wrong default value for.
I'll package a new version that should revert that setting to the correct value.
Until then, you can add this in your /etc/greyhole.conf:
check_for_open_files = true
#4 Updated by gboudreau almost 10 years ago
sidelight: install the new version to fix this:rpm -Uvh http://www.greyhole.net/releases/hda-greyhole-0.9.2-1.`uname -i`.rpm
#5 Updated by sidelight almost 10 years ago
Thanks that seems to have fixed it :-)
Also available in: Atom