I may not be phrasing my question correctly, but I'll do my best to explain the symptoms I'm experiencing. First, for context, I'm running an Ubuntu server (no GUI), version 12.04.3 LTS (according the the lsb_release utility). I generally do all of my work in tmux, I connect to the server via Putty, and I use vim for all my text editing.

Now for the symptoms. Since I use tmux, I usually have a few windows open at all times. One of them houses a node server I've been playing around with, and it lives in a subdirectory of my user account's home (specifically, ~/battleship). The server interacts with a webpage I'm also hosting off of the server using nginx, and all the website code lives in /usr/share/nginx/www/bs (I also keep a separate window open for editing the client source). What happens is that after several hours of leaving the server window idle and untouched, it seems to fall out of sync. I can run ls and see the files, and I can open them for editing (vim server.js). When I do that, however, regardless of whether I make changes and save or just quit out instantly, when I run ls again I see a .server.js.swp file, and none of my changes (if I made any) persist. If I move out of that directory and then back in, it fixes itself - I can open the file and edit it successfully, without leaving behind a .swp when I close it. I mentioned the client source half of things because I've noticed that this doesn't happen in the /www folder (presumably because it's outside of my user account's home directory).

After that wall of text, my question is this: Does anyone know why this is happening, and how to prevent it? I can only imagine there's some way, considering that this isn't the only Linux server I connect to via Putty and use tmux/vim on, and yet it's the only one where this weird behavior happens. Any help would be appreciated.

Note: I tagged this with bash, tmux, and putty because I'm assuming one of them is to blame but I really have no clue which.

Update: This is the output of cat /proc/mount as requested by Gilles (albeit with my username and the values of ecryptfs_fnek_sig and ecryptfs_sig censored, because while I don't actually know what those two things are, they seem encryption-related, and better safe than sorry).

rootfs / rootfs rw 0 0
sysfs /sys sysfs rw,nosuid,nodev,noexec,relatime 0 0
proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0
udev /dev devtmpfs rw,relatime,size=2008532k,nr_inodes=502133,mode=755 0 0
devpts /dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0
tmpfs /run tmpfs rw,nosuid,relatime,size=807840k,mode=755 0 0
/dev/disk/by-uuid/2da27263-f079-47ba-90ad-66e4c3a53810 / ext4 rw,relatime,errors=remount-ro,data=ordered 0 0
none /sys/fs/fuse/connections fusectl rw,relatime 0 0
none /sys/kernel/debug debugfs rw,relatime 0 0
none /sys/kernel/security securityfs rw,relatime 0 0
none /run/lock tmpfs rw,nosuid,nodev,noexec,relatime,size=5120k 0 0
none /run/shm tmpfs rw,nosuid,nodev,relatime 0 0
/home/[username]/.Private /home/[username] ecryptfs rw,relatime,ecryptfs_fnek_sig=[censored],ecryptfs_sig=[censored],ecryptfs_cipher=aes,ecryptfs_key_bytes=16,ecryptfs_unlink_sigs 0 0

Update 2: Here's the output of uname -a:

Linux [server-name] 3.5.0-39-generic #60~precise1-Ubuntu SMP Wed Aug 14 15:38:41 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

Update 3: I completed a pass of memtest. This is the result of said test. Seems to have completed with no errors, so I'm not sure if it will end up helping with anything. You can also see some hardware details in case that helps in any way.

  • 3
    No, bash cannot “get out of sync with the filesystem”, and that's not what's happening anyway. It's more like the filesystem is getting out of sync with the filesystem. It's definitely a problem, and a weird one at that. What filesystem(s) are you using (post the output of cat /proc/mounts)? This is probably a virtualized server, what kind of virtualization is it using? Sep 6, 2013 at 20:19
  • 1
    @Gilles I updated the question to include the output of cat /proc/mounts for you. Hopefully that will mean something to you - I'm still pretty new to Linux, so there's been a lot of learning by doing, and I haven't poked around with the filesystem at all yet (beyond using it).
    – Alex
    Sep 6, 2013 at 20:28
  • 4
    So the problem occurs on an ecryptfs filesystem. This looks like a bug in ecryptfs, or in other parts of the kernel, or in the virtualization software if applicable, or a hardware fault. Is this running on your own hardware in a box or on a rack, or is this a virtualized server with some hosting provider? What's the output of uname -a? If it's your hardware, plug in a console and do a memory test on the next boot. If it's hosted, contact your hosting provider and describe these symptoms. Sep 6, 2013 at 20:43
  • 1
    If you run sudo sync does the files get updated?
    – Braiam
    Sep 15, 2013 at 1:28
  • 1
    Do try the sync command. Also the df cmd is handy to show where a dir lives. Like /proc/mount but more readable output. Do df -h /www ~/battleship /usr/share/nginx/www/bs. Is the problem with the encryptfs mounts? Maybe extra sw processing is needed for writes to that disc so there is caching or something happening to do with that?
    – gaoithe
    Mar 25, 2014 at 0:00

3 Answers 3


The only experience I've seen with something like this was when a directory was being removed and a new one created. AIX and Solaris had this issue years back. If you have an open shell session in a removed directory you can get unpredictable results back that look like a file system getting out of sync.

bash1: mkdir test1
bash2: cd test1
bash1: touch test1/testfile
bash1: ls test1
bash2: ls
bash1: rm -rf test1
bash2: ls
???(unknown results)???

The encrypted file system sounds like something to review as well. Have you tried in an unencrypted file system?

Sorry I cannot post comments yet. Not enough points.

  • This is relevant to the question, with a bash shell left with a default directory which does not exist, and in which it is impossible to create files.
    – ubfan1
    Mar 23, 2014 at 22:23
  • 1
    I can try this little experiment, but I'm fairly confident at this point that it's an ecryptfs issue. The directories in question definitely still exist; I can work normally after a simple cd . when I come back to a session after a while. At this point I'm honestly just considering backing everything up, wiping the server, and reinstalling without an encrypted filesystem. I don't keep anything remotely important on it, so I'm not too concerned about encrypting my files.
    – Alex
    Mar 25, 2014 at 18:52
  • The eCryptfs maintainer/author in Ubuntu is very responsive to bug reports. If you can't find a solution, it's probably worth asking him or filing a bug report.
    – user41313
    May 4, 2014 at 2:00

FWIW the issue is displayed by the ls command, not by bash.

The fact that you see the file means it is still there. Nothing is out of sync with anything else and no amount of running sync will stop you from using the only cached copy of the relevant file system data. sync will just cause the data to commit to permanent storage, not change your view of it.

Are you using VIM sessions? I don't know VIM session, never used it myself, but I imagine tmux might cause the VI session manager to not realize the file is closed and to keep your changes being tracked.


You could try running the sync command in between your bash commands.

sync - flush file system buffers

I have never found the need for that myself but have known at least one person who typed it practically as every second command! Must have been burned badly in the past with slow disk.

The internet seems to be light on discussion of the use of the sync command. Here is a link to very short manual entry for sync: http://www.gnu.org/software/coreutils/manual/html_node/sync-invocation.html

sync guarantees that data is written from memory to disk device. The data could still be in disk device cache memory and not written to disk if the disk device itself is slow or has a problem.

You are running an ubuntu server . . . is that a machine on your desktop? Or is it in a cloud? Or . . . something else? See here: https://serverfault.com/questions/534627/what-does-the-sync-command-do slow sync from memory to disc associated with hard disk problems OR maybe with Amazon AWS smaller instances.

  • 1
    I'm not sure if sync will be of any use; I've found that just doing cd . mitigates the issue anyway. I made an alias ref for it (I know, saving one character is a bit silly) which I'm in the habit of using every time I come back to an old session now. As for what the server is, it's my old desktop tower (I built a new one last year) that now lives in the corner of my living room running the Ubuntu distro, so I do have full access to the hardware and power over what's running on it.
    – Alex
    Mar 25, 2014 at 18:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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