Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Have a situation where we have an application log sitting out on an AIX server. The log is being continually written to from the application, and we have users on Windows who want to view the file. What they've been doing is using WinSCP to transfer the file to their desktop and they open it using a text editor.

What I think might be happening is scp is locking the file for the duration of the transfer, and the application ceases to be able to write to the file. The reason I believe this is the log file will stop growing at random points during the day.

Is that what perhaps is going on?

share|improve this question
I think that an aix tag would be welcome. – Cristian Ciupitu Mar 5 '10 at 16:28
up vote 7 down vote accepted

Why don't you try this. Start scp'ing a large file then run lsof /path/to/file on the AIX server and see what the FD column says.

From the lsof man page:

   FD         is the File Descriptor number of the file or:
                   cwd  current working directory;
                   Lnn  library references (AIX);
                   err  FD information error (see NAME column);
                   jld  jail directory (FreeBSD);
                   ltx  shared library text (code and data);
                   Mxx  hex memory-mapped type number xx.
                   m86  DOS Merge mapped file;
                   mem  memory-mapped file;
                   mmap memory-mapped device;
                   pd   parent directory;
                   rtd  root directory;
                   tr   kernel trace file (OpenBSD);
                   txt  program text (code and data);
                   v86  VP/ix mapped file;
              FD is followed by one of these characters, describing the mode under which the file is open:
                   r for read access;
                   w for write access;
                   u for read and write access;
                   space if mode unknown and no lock
                        character follows;
                   `-' if mode unknown and lock
                        character follows.
              The mode character is followed by one of these lock characters, describing the type of lock applied to the file:
                   N for a Solaris NFS lock of unknown type;
                   r for read lock on part of the file;
                   R for a read lock on the entire file;
                   w for a write lock on part of the file;
                   W for a write lock on the entire file;
                   u for a read and write lock of any length;
                   U for a lock of unknown type;
                   x for an SCO OpenServer Xenix lock on part of the file;
                   X for an SCO OpenServer Xenix lock on the entire file;
                   space if there is no lock.
              See the LOCKS section for more information on the lock information character.
              The FD column contents constitutes a single field for parsing in post-processing scripts.

If you do this, on Linux at least, you'll see that the FD column is "3r" which means it has some sort of read lock but I'm not sure what the 3 in front of it means.

share|improve this answer
FYI, yup it puts that read lock on the file! Thanks! – ThaDon Mar 5 '10 at 17:56
Oh, actually small r indicates a lock on only part of the file, perhaps scp isn't the problem then... – ThaDon Mar 5 '10 at 19:14
That's correct the small r indicates that it's a byte lock. So in theory it's only locking the portion it's currently sending. But if you read the lsof man page on locking it also says that it may not report the locking accurately in some cases. You may want to setup an experiment where you have a large text file...start scp'ing it and then do something like echo "blah blah blah" >> textfile. If that successfully adds it to the end of the file then I would say that what lsof is reporting is correct. – 3dinfluence Mar 5 '10 at 20:04

Most Unix programs don't use locking or when they use it, it's not mandatory, so I doubt locking is stopping your log from growing. More likely the SCP transfer is slowing down the log writing.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.