4

I have a Ubuntu 14.04 server that will lock up after an undetermined amount of time when you attempt to tab-auto-complete the path of a CIFS share in the /mnt directory. I mount the share and it seems to work fine for a uncertain amount of time. I can do ls or run du on folders within the mounted share. Then I will go to tab out a folder path and my console locks up. I can start a new session but it will lock as soon as I try to mess with the mounted share; this even happens to other users if I have them try as well. I have no idea why this is happening? I've never seen this issue.

4
  • 1
    This problem happens when there is a problem connecting to the server, either the server is down you you have a problem in networking. FWIW, graphical tools will lock up as well.
    – Panther
    May 22, 2014 at 22:24
  • See for example - stackoverflow.com/questions/74626/…
    – Panther
    May 22, 2014 at 22:25
  • Why that appears similar, my network connection remains fine. The remote server is still available <15ms latency. Also, I can umount the share with no problem, whereas that user cannot. May 22, 2014 at 22:37
  • I've not ever seen this problem outside of a problem with server / network issues. Hard to know as you are sort of asking two different questions, your problem with uses is likely one of permissions.
    – Panther
    May 22, 2014 at 22:59

1 Answer 1

1

This has to do with both the way bash completion works and the way cifs works as a protocol.

bash completion works thusly:

  1. readline informs bash of the currently-typed string, and of the tab keystroke.
  2. bash performs a Depth First Searchof the filesystem, the root of which is at the most-matched part of the filesystem hierarchy. Each step of this search is actually many requests - a request for a list - from the filesystem.
  3. readline blocks - waiting for a response from bash with a list of possible outcomes to display.
  4. that list arrives, readline displays it, and returns input control to the user.

On a blocklevel or local or otherwise reasonably-fast filesystem, this all happens incredibly quickly.

CIFS, unfortunately, isn't a blocklevel filesystem. Instead, CIFS is a command-based transactional protocol. Every single request made against CIFS is:

  • transactional, requiring a request, acknowledgement, and acknowledgement of the acknowledgement,
  • represented by multiple individual CIFS/SMB command blocks
  • inspected for authentication

In short, CIFS/SMB is (at least in SMB1, which almost assuredly is what you're using to mount this CIFS share) extremely chatty.

In ordinary, direct usage of known filenames, the request is a singleton. You make the request for a file, CIFS authenticates you, acknowledges your request, you acknowledge their acknowledgement, and your file transfers.

In the case of tab-completion, that cycle is multiplied by the number of files in a particular directory, possibly times two (or more!) if it's dereferencing a Windows Shortcut.

All over the network.

This is a recipe for significant slowdowns as readline waits for bash who's in turn waiting for the filesystem driver to negotiate with the CIFS server.

You may wish to work around this problem by doing things like running your session from within screen, that way if your bash session locks up, you can ctrl-A-c and get s brand spanking new terminal, so you can continue to work or even kill the other one.

2
  • Thanks for the detailed description of the problem. Are you aware of a simple way to restrict this search inside bash? Aug 15, 2014 at 13:00
  • The easy answer is to do it the old-fashioned way: don't rely on tab completion. Instead, do an 'ls' of wherever you're looking for things, and type the path out completely rather than trying to tab-complete. I susopect (but don't know for sure) that tab-completion may be able to be configured not to span remote filesystems, which would also do what you want.
    – James S.
    Aug 20, 2014 at 18:46

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .