Bug 839294 - tar --create fails to open file (with exit 2) when the kernel lease is established by Samba
Summary: tar --create fails to open file (with exit 2) when the kernel lease is establ...
Keywords:
Status: CLOSED INSUFFICIENT_DATA
Alias: None
Product: Fedora
Classification: Fedora
Component: tar
Version: 19
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Pavel Raiskup
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-07-11 13:35 UTC by Need Real Name
Modified: 2023-09-14 01:30 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-01-15 07:19:21 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
try to open kernel-lease blocked file multiple times (3.48 KB, text/plain)
2012-07-16 08:53 UTC, Pavel Raiskup
no flags Details

Description Need Real Name 2012-07-11 13:35:53 UTC
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.

Comment 1 Pavel Raiskup 2012-07-11 17:27:17 UTC
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

Comment 2 Need Real Name 2012-07-11 20:48:02 UTC
>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.

Comment 3 Need Real Name 2012-07-11 20:59:26 UTC
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.

Comment 4 Need Real Name 2012-07-12 17:25:05 UTC
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.

Comment 5 Need Real Name 2012-07-14 11:13:08 UTC
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.

Comment 6 Pavel Raiskup 2012-07-16 08:53:06 UTC
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

Comment 7 Need Real Name 2012-07-22 08:34:49 UTC
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

Comment 8 Pavel Raiskup 2012-07-23 07:50:44 UTC
> 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

Comment 9 Pavel Raiskup 2012-08-28 11:26:29 UTC
Changed the summary to better describe the problem.

Comment 10 Fedora End Of Life 2013-07-04 06:27:30 UTC
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.

Comment 11 Pavel Raiskup 2013-07-04 10:49:35 UTC
> 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.

Comment 12 Red Hat Bugzilla 2023-09-14 01:30:40 UTC
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days


Note You need to log in before you can comment on or make changes to this bug.