Local file locking on NFS being Linux Kernel dependent

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP











up vote
3
down vote

favorite
1












I have an python2 application which needs work on files over NFS. Unfortunately the application uses flock() locks like this:



#!/usr/bin/env python2

import fcntl

print('Opening')
foo = open('file/on/NFS/share')
print('Locking')
fcntl.flock(foo, fcntl.LOCK_EX)
print('Closing')
foo.close()


which fails:



Opening
Locking
Traceback (most recent call last):
File "./flock_lock.py", line 8, in <module>
fcntl.flock(foo, fcntl.LOCK_EX)
IOError: [Errno 9] Bad file descriptor


If I change the fcntl.flock() to fcntl.fcntl() the locking works. However this is only test code. I cannot change any code from the production application. This is not a code problem so I believe it belongs here.



I've mounted the NFS share with nolock and/or local_lock=all.

According to nfs(5):




When using the nolock option, applications can lock files, but such locks provide exclusion only against other applications running on the same client.




(also see D10 here)



and:




Specifies whether to use local locking for any or both of the flock and the POSIX locking mechanisms. [...] The Linux NFS client provides a way to make locks local. This means, the applications can lock files, but such locks provide exclusion only against other applications running on the same client.




I'm not quite sure what is the difference between them, but shouldn't those option enable local-only locks (which is fine for me) and prevent IO-errors ?



flock(2) says:




In Linux kernels up to 2.6.11, flock() does not lock files over NFS (i.e., the scope of locks was limited to the local system). [...] Since Linux 2.6.12, NFS clients support flock() locks by emulating them as byte-range locks on the entire file.




The NFS server and the NFS client are both running Scientific Linux 7.4 (very similar to CentOS) with Kernel 3.10.

Shouldn't Kernel 3.10 be able to lock NFS files with flock() ?



I tried mounting the NFS share on an Ubuntu 16.04 (Kernel 4.4.0) host and the locking works fine!

I then updated the Scientific Linux Client to kernel 4.4.91 and it works too!

While this is great I would be much more comfortable running the production client with its stock kernel 3.10.



Question: How can I mount the share with working local locks (without updating the kernel) on stock kernel 3.10 ?



Bonus: Why don't the nolock and local_lock=all mount options do what they say? Am I misunderstanding the man pages?

Why doesn't flock() work on kernel > 2.6.11 even though the man page says it does?

Why does upgrading to kernel 4.4 fix the problem ?










share|improve this question



























    up vote
    3
    down vote

    favorite
    1












    I have an python2 application which needs work on files over NFS. Unfortunately the application uses flock() locks like this:



    #!/usr/bin/env python2

    import fcntl

    print('Opening')
    foo = open('file/on/NFS/share')
    print('Locking')
    fcntl.flock(foo, fcntl.LOCK_EX)
    print('Closing')
    foo.close()


    which fails:



    Opening
    Locking
    Traceback (most recent call last):
    File "./flock_lock.py", line 8, in <module>
    fcntl.flock(foo, fcntl.LOCK_EX)
    IOError: [Errno 9] Bad file descriptor


    If I change the fcntl.flock() to fcntl.fcntl() the locking works. However this is only test code. I cannot change any code from the production application. This is not a code problem so I believe it belongs here.



    I've mounted the NFS share with nolock and/or local_lock=all.

    According to nfs(5):




    When using the nolock option, applications can lock files, but such locks provide exclusion only against other applications running on the same client.




    (also see D10 here)



    and:




    Specifies whether to use local locking for any or both of the flock and the POSIX locking mechanisms. [...] The Linux NFS client provides a way to make locks local. This means, the applications can lock files, but such locks provide exclusion only against other applications running on the same client.




    I'm not quite sure what is the difference between them, but shouldn't those option enable local-only locks (which is fine for me) and prevent IO-errors ?



    flock(2) says:




    In Linux kernels up to 2.6.11, flock() does not lock files over NFS (i.e., the scope of locks was limited to the local system). [...] Since Linux 2.6.12, NFS clients support flock() locks by emulating them as byte-range locks on the entire file.




    The NFS server and the NFS client are both running Scientific Linux 7.4 (very similar to CentOS) with Kernel 3.10.

    Shouldn't Kernel 3.10 be able to lock NFS files with flock() ?



    I tried mounting the NFS share on an Ubuntu 16.04 (Kernel 4.4.0) host and the locking works fine!

    I then updated the Scientific Linux Client to kernel 4.4.91 and it works too!

    While this is great I would be much more comfortable running the production client with its stock kernel 3.10.



    Question: How can I mount the share with working local locks (without updating the kernel) on stock kernel 3.10 ?



    Bonus: Why don't the nolock and local_lock=all mount options do what they say? Am I misunderstanding the man pages?

    Why doesn't flock() work on kernel > 2.6.11 even though the man page says it does?

    Why does upgrading to kernel 4.4 fix the problem ?










    share|improve this question

























      up vote
      3
      down vote

      favorite
      1









      up vote
      3
      down vote

      favorite
      1






      1





      I have an python2 application which needs work on files over NFS. Unfortunately the application uses flock() locks like this:



      #!/usr/bin/env python2

      import fcntl

      print('Opening')
      foo = open('file/on/NFS/share')
      print('Locking')
      fcntl.flock(foo, fcntl.LOCK_EX)
      print('Closing')
      foo.close()


      which fails:



      Opening
      Locking
      Traceback (most recent call last):
      File "./flock_lock.py", line 8, in <module>
      fcntl.flock(foo, fcntl.LOCK_EX)
      IOError: [Errno 9] Bad file descriptor


      If I change the fcntl.flock() to fcntl.fcntl() the locking works. However this is only test code. I cannot change any code from the production application. This is not a code problem so I believe it belongs here.



      I've mounted the NFS share with nolock and/or local_lock=all.

      According to nfs(5):




      When using the nolock option, applications can lock files, but such locks provide exclusion only against other applications running on the same client.




      (also see D10 here)



      and:




      Specifies whether to use local locking for any or both of the flock and the POSIX locking mechanisms. [...] The Linux NFS client provides a way to make locks local. This means, the applications can lock files, but such locks provide exclusion only against other applications running on the same client.




      I'm not quite sure what is the difference between them, but shouldn't those option enable local-only locks (which is fine for me) and prevent IO-errors ?



      flock(2) says:




      In Linux kernels up to 2.6.11, flock() does not lock files over NFS (i.e., the scope of locks was limited to the local system). [...] Since Linux 2.6.12, NFS clients support flock() locks by emulating them as byte-range locks on the entire file.




      The NFS server and the NFS client are both running Scientific Linux 7.4 (very similar to CentOS) with Kernel 3.10.

      Shouldn't Kernel 3.10 be able to lock NFS files with flock() ?



      I tried mounting the NFS share on an Ubuntu 16.04 (Kernel 4.4.0) host and the locking works fine!

      I then updated the Scientific Linux Client to kernel 4.4.91 and it works too!

      While this is great I would be much more comfortable running the production client with its stock kernel 3.10.



      Question: How can I mount the share with working local locks (without updating the kernel) on stock kernel 3.10 ?



      Bonus: Why don't the nolock and local_lock=all mount options do what they say? Am I misunderstanding the man pages?

      Why doesn't flock() work on kernel > 2.6.11 even though the man page says it does?

      Why does upgrading to kernel 4.4 fix the problem ?










      share|improve this question















      I have an python2 application which needs work on files over NFS. Unfortunately the application uses flock() locks like this:



      #!/usr/bin/env python2

      import fcntl

      print('Opening')
      foo = open('file/on/NFS/share')
      print('Locking')
      fcntl.flock(foo, fcntl.LOCK_EX)
      print('Closing')
      foo.close()


      which fails:



      Opening
      Locking
      Traceback (most recent call last):
      File "./flock_lock.py", line 8, in <module>
      fcntl.flock(foo, fcntl.LOCK_EX)
      IOError: [Errno 9] Bad file descriptor


      If I change the fcntl.flock() to fcntl.fcntl() the locking works. However this is only test code. I cannot change any code from the production application. This is not a code problem so I believe it belongs here.



      I've mounted the NFS share with nolock and/or local_lock=all.

      According to nfs(5):




      When using the nolock option, applications can lock files, but such locks provide exclusion only against other applications running on the same client.




      (also see D10 here)



      and:




      Specifies whether to use local locking for any or both of the flock and the POSIX locking mechanisms. [...] The Linux NFS client provides a way to make locks local. This means, the applications can lock files, but such locks provide exclusion only against other applications running on the same client.




      I'm not quite sure what is the difference between them, but shouldn't those option enable local-only locks (which is fine for me) and prevent IO-errors ?



      flock(2) says:




      In Linux kernels up to 2.6.11, flock() does not lock files over NFS (i.e., the scope of locks was limited to the local system). [...] Since Linux 2.6.12, NFS clients support flock() locks by emulating them as byte-range locks on the entire file.




      The NFS server and the NFS client are both running Scientific Linux 7.4 (very similar to CentOS) with Kernel 3.10.

      Shouldn't Kernel 3.10 be able to lock NFS files with flock() ?



      I tried mounting the NFS share on an Ubuntu 16.04 (Kernel 4.4.0) host and the locking works fine!

      I then updated the Scientific Linux Client to kernel 4.4.91 and it works too!

      While this is great I would be much more comfortable running the production client with its stock kernel 3.10.



      Question: How can I mount the share with working local locks (without updating the kernel) on stock kernel 3.10 ?



      Bonus: Why don't the nolock and local_lock=all mount options do what they say? Am I misunderstanding the man pages?

      Why doesn't flock() work on kernel > 2.6.11 even though the man page says it does?

      Why does upgrading to kernel 4.4 fix the problem ?







      centos nfs scientific-linux






      share|improve this question















      share|improve this question













      share|improve this question




      share|improve this question








      edited Oct 8 '17 at 18:59

























      asked Oct 8 '17 at 18:33









      Ansgar

      414




      414




















          1 Answer
          1






          active

          oldest

          votes

















          up vote
          0
          down vote



          accepted










          I reported this behaviour to RedHat. It was actually caused by a bug in the RedHat Kernel and was fixed in kernel-3.10.0-693.18.1.el7.
          At least for NFSv3. For NFSv4 this seems to be the desired behaviour.



          If you have a RedHat Subscription you can look up the Ticket: Ticket 01951116






          share|improve this answer




















            Your Answer







            StackExchange.ready(function()
            var channelOptions =
            tags: "".split(" "),
            id: "106"
            ;
            initTagRenderer("".split(" "), "".split(" "), channelOptions);

            StackExchange.using("externalEditor", function()
            // Have to fire editor after snippets, if snippets enabled
            if (StackExchange.settings.snippets.snippetsEnabled)
            StackExchange.using("snippets", function()
            createEditor();
            );

            else
            createEditor();

            );

            function createEditor()
            StackExchange.prepareEditor(
            heartbeatType: 'answer',
            convertImagesToLinks: false,
            noModals: false,
            showLowRepImageUploadWarning: true,
            reputationToPostImages: null,
            bindNavPrevention: true,
            postfix: "",
            onDemand: true,
            discardSelector: ".discard-answer"
            ,immediatelyShowMarkdownHelp:true
            );



            );













             

            draft saved


            draft discarded


















            StackExchange.ready(
            function ()
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f396886%2flocal-file-locking-on-nfs-being-linux-kernel-dependent%23new-answer', 'question_page');

            );

            Post as a guest






























            1 Answer
            1






            active

            oldest

            votes








            1 Answer
            1






            active

            oldest

            votes









            active

            oldest

            votes






            active

            oldest

            votes








            up vote
            0
            down vote



            accepted










            I reported this behaviour to RedHat. It was actually caused by a bug in the RedHat Kernel and was fixed in kernel-3.10.0-693.18.1.el7.
            At least for NFSv3. For NFSv4 this seems to be the desired behaviour.



            If you have a RedHat Subscription you can look up the Ticket: Ticket 01951116






            share|improve this answer
























              up vote
              0
              down vote



              accepted










              I reported this behaviour to RedHat. It was actually caused by a bug in the RedHat Kernel and was fixed in kernel-3.10.0-693.18.1.el7.
              At least for NFSv3. For NFSv4 this seems to be the desired behaviour.



              If you have a RedHat Subscription you can look up the Ticket: Ticket 01951116






              share|improve this answer






















                up vote
                0
                down vote



                accepted







                up vote
                0
                down vote



                accepted






                I reported this behaviour to RedHat. It was actually caused by a bug in the RedHat Kernel and was fixed in kernel-3.10.0-693.18.1.el7.
                At least for NFSv3. For NFSv4 this seems to be the desired behaviour.



                If you have a RedHat Subscription you can look up the Ticket: Ticket 01951116






                share|improve this answer












                I reported this behaviour to RedHat. It was actually caused by a bug in the RedHat Kernel and was fixed in kernel-3.10.0-693.18.1.el7.
                At least for NFSv3. For NFSv4 this seems to be the desired behaviour.



                If you have a RedHat Subscription you can look up the Ticket: Ticket 01951116







                share|improve this answer












                share|improve this answer



                share|improve this answer










                answered Apr 13 at 8:49









                Ansgar

                414




                414



























                     

                    draft saved


                    draft discarded















































                     


                    draft saved


                    draft discarded














                    StackExchange.ready(
                    function ()
                    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f396886%2flocal-file-locking-on-nfs-being-linux-kernel-dependent%23new-answer', 'question_page');

                    );

                    Post as a guest













































































                    Popular posts from this blog

                    How to check contact read email or not when send email to Individual?

                    Displaying single band from multi-band raster using QGIS

                    How many registers does an x86_64 CPU actually have?