File locking on some NFS mounts

[Malcolm Tredinnick]

There are still some NFS configurations that are failing to lock files the way we try. The information below is reposted from a comment in #8403 (moving here, since that ticket is about a different sort of error that we have fixed):

Traceback:
File "/usr/lib/python2.4/site-packages/django/core/handlers/base.py" in get_response
  86.                 response = callback(request, *callback_args, **callback_kwargs)
File "/usr/lib/python2.4/site-packages/django/contrib/admin/sites.py" in root
  158.                 return self.model_page(request, *url.split('/', 2))
File "/usr/lib/python2.4/site-packages/django/views/decorators/cache.py" in _wrapped_view_func
  44.         response = view_func(request, *args, **kwargs)
File "/usr/lib/python2.4/site-packages/django/contrib/admin/sites.py" in model_page
  177.         return admin_obj(request, rest_of_url)
File "/usr/lib/python2.4/site-packages/django/contrib/admin/options.py" in __call__
  197.             return self.change_view(request, unquote(url))
File "/usr/lib/python2.4/site-packages/django/db/transaction.py" in _commit_on_success
  238.                 res = func(*args, **kw)
File "/usr/lib/python2.4/site-packages/django/contrib/admin/options.py" in change_view
  579.                 new_object = self.save_form(request, form, change=True)
File "/usr/lib/python2.4/site-packages/django/contrib/admin/options.py" in save_form
  370.         return form.save(commit=False)
File "/usr/lib/python2.4/site-packages/django/forms/models.py" in save
  302.         return save_instance(self, self.instance, self._meta.fields, fail_message, commit)
File "/usr/lib/python2.4/site-packages/django/forms/models.py" in save_instance
  47.         f.save_form_data(instance, cleaned_data[f.name])
File "/usr/lib/python2.4/site-packages/django/db/models/fields/files.py" in save_form_data
  192.             getattr(instance, self.name).save(data.name, data, save=False)
File "/usr/lib/python2.4/site-packages/django/db/models/fields/files.py" in save
  217.         super(ImageFieldFile, self).save(name, content, save)
File "/usr/lib/python2.4/site-packages/django/db/models/fields/files.py" in save
  74.         self._name = self.storage.save(name, content)
File "/usr/lib/python2.4/site-packages/django/core/files/storage.py" in save
  45.         name = self._save(name, content)
File "/usr/lib/python2.4/site-packages/django/core/files/storage.py" in _save
  150.                     file_move_safe(content.temporary_file_path(), full_path)
File "/usr/lib/python2.4/site-packages/django/core/files/move.py" in file_move_safe
  70.             locks.lock(fd, locks.LOCK_EX)
File "/usr/lib/python2.4/site-packages/django/core/files/locks.py" in lock
  57.         fcntl.lockf(fd(file), flags)

Exception Type: IOError at /program/event/1109/
Exception Value: [Errno 5] Input/output error

• OS: Debian Etch
• export options: (rw,sync,no_subtree_check)
• nfsd and client nfs tools versions: 1.0.10-6+etch.1
• options from the mount: rw,vers=3,rsize=32768,wsize=32768,hard,intr,proto=tcp,timeo=600,retrans=2,sec=sys,addr=vm1 0 0

[Malcolm Tredinnick]

Based on the information you've provided, in particular the Debian package versions, there's a good chance you might be hitting this problem: ​http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=432511 .

If so, this isn't a problem Django should fix, since it's a system configuration issue with one particular set of packages. You can either manually start rpc.statd and then nfsd, or upgrade the Debian package or rejig the startup scripts. I'll leave this open for a bit pending confirmation that that Debian bug is the problem (it's not going to be enough to check that statd is running; it must have been started *before* nfsd). If it is, please close this.

If not, it starts to get tricky, because the only reports of seen of this are Debian Etch systems running 1.0.10 (this ticket plus two others now. Turned out that version on that distro was the common factor). We're doing the right sort of file locking for NFS in general, so it starts to looks like a config issue, but I'm not sure what the issue could be. Anyway, feedback on whether that bug report (well, the fix for that report) is the solution is now sought.

[Malcolm Tredinnick]

I just received confirmation from one person I know was seeing this problem that upgrading the nfs package in Debian fixed the problem for them (and they were seeing this case). So I'm going to close this.

If anybody else sees this problem and wishes to reopen, we're going to need information about whether any kind of file locking works on the particular NFS mount you are trying to use. That might require consultation with your system administrator. Locking has to be possible for this stuff to work (that was the root problem in the Debian bug report: things were configured so that remote locks weren't going to be possible).

As always, version numbers (if using Debian, make sure to be using nfs-1.0.11 or later) will be appropriate, too. The original report here was actually very good in providing the sort of information we need.