Current tar version often fails with exit code 2, because of locking problem. tar: /home/ccccccc/ffffff.pdf: Cannot open: Resource temporarily unavailable the files are shared through samba, and tar fails to read files opened by samba. rpm -q tar tar-1.26-6.fc17.x86_64 This tar problem is known. This patch http://lists.gnu.org/archive/html/bug-tar/2012-01/msg00013.html is expected to fix the problem. I did not try it, but other people report positive results. As it is now - it is unacceptable. The backups used to work OK, and after ugrade to fedora 17 they started to fail.
Hi, thanks for the report. > Current tar version often fails with exit code 2, because of locking problem. > tar: /home/ccccccc/ffffff.pdf: Cannot open: Resource temporarily unavailable > the files are shared through samba, and tar fails to read files opened by > samba. > > rpm -q tar > tar-1.26-6.fc17.x86_64 > > > This tar problem is known. This patch > http://lists.gnu.org/archive/html/bug-tar/2012-01/msg00013.html > is expected to fix the problem. I did not try it, but other people > report positive results. IIRC, mentioned patch is related to that situation you have successfully opened file descriptor but you are not able to _read_ from it. It means it can not help you with EAGAIN/EWOULDBLOCK regarding to open(2). > As it is now - it is unacceptable. The backups used to work OK, and after > ugrade to fedora 17 they started to fail. It seems that samba has taken a lease for archived file and tar's role is "lease breaker" according to fcntl(2) man page. In a case that the samba's behaviour is ok, we could repeat the non-blocking open(2) call for some time to wait until samba does not decrease its lease for some seconds (at most to /proc/sys/fs/lease-break-time seconds). And this would be good improvement IMO. But, for now it looks that there is a problem in samba (as it looks that it happens only _after_ upgrade to fedora 17 reliably -- not sometimes). Is it true that samba wants nobody to read the mentioned pdf? I'm not familiar with samba but it looks that 'smbstatus' is showing some "locking" info. Pavel
>as it looks that it happens only _after_ upgrade to fedora 17 reliably -- not sometimes Yes. I did not have this problem with older versions of samba & tar. All reported files with "Cannot open: Resource temporarily " message are files opened by WindowsPC user through samba. /home/xxxxx/~$Daily Tasks Lite.xlsx: Cannot open: Resource temporarily unavailable tar: /home/xxxxx/Temp/~$Book11.xlsx: Cannot open: Resource temporarily unavailable tar: /home/xxxx/Reference/~$Ops Checklist.xlsx: Cannot open: Resource temporarily unavailable No other file have "Resource temporarily unavailable" message.
I just put in smb.conf kernel oplocks = false and I will see what would happen. I believe this will make backups working again. But I think tar should be somehow fixed for this issue.
After settings in smb.conf kernel oplocks = false three consequtive backups passed OK. I think tar should be somehow fixed for this issue, otherwise it cannot realy copy locked files.
No problem since I set kernel oplocks = false in smb.conf tar should be fixed somehow. It may be to create a list of files to be tried to read later, or something else. As it is now - tar just stops working when kernel oplocks are used.
Created attachment 598396 [details] try to open kernel-lease blocked file multiple times > After settings in smb.conf > kernel oplocks = false > three consequtive backups passed OK. Thanks for finding workaround. > It may be to create a list of files to be tried to read later, > or something else. The main problem of this lease non-compatibility (I don't think it is a tar bug) is that there is no generally satisfactory solution. The non-blocking open() can't be considered due to security reasons -- and because we don't know how long will be the lease taken -- we can just guess and try to wait for it by trying to open this file in non-blocking mode (and die after user predefined count of tries). Making another list of delayed files would be quite large edit with uncertain future. You can look at/try attached patch done against fedora-17 proposing "--lease-wait-count" and "--lease-wait-period" options. By these options you may specify how long will tar try to open the kernel-lease locked file. I'll try to consult this with upstream if it helps you with samba issue. Pavel
with applied patch tar: /home/xxxxxxxxxxx/Outlook/~YYYYYYYYYY.pst.tmp: Cannot open: Resource temporarily unavailable I just applied & recompiled, no non-default --lease-wait-count" and "--lease-wait-period is set just applied & recompiled
> tar: /home/xxxxxxxxxxx/Outlook/~YYYYYYYYYY.pst.tmp: Cannot open: Resource > temporarily unavailable > [...] > no non-default --lease-wait-count" and "--lease-wait-period is set Thats expected behavior. It is not good idea to wait by default for possibly infinitely long period of time -- we really don't know how long the lease will be taken. Try to use --lease-wait-count=100 (for waiting at most one second per file). Samba should allow you to read mentioned file. If not, there is (or should be) probably good reason not to read mentioned file at the moment and fail respectfully. In that case please try cat the responsible file if samba even allows you to read the file. Here you have scratch build for testing purposes only: http://koji.fedoraproject.org/koji/taskinfo?taskID=4322322 Pavel
Changed the summary to better describe the problem.
This message is a reminder that Fedora 17 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 17. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '17'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 17's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 17 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior to Fedora 17's end of life. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
> Try to use --lease-wait-count=100 (for waiting at most one second per file). > Samba should allow you to read mentioned file. If not, there is (or should > be) probably good reason not to read mentioned file at the moment and fail > respectfully. In that case please try cat the responsible file if samba even > allows you to read the file. Could you please try to use this ^^. Actually, I was unable to reproduce your problem and I thus don't want to try to propose this until I know that the fix actually fixes something. Thanks.
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days