Description

While using sample-loader (either beer-sample or gamesim-sample) to load on sample buckets on the couchbase server (on the web console and not using the command line), an "unexpected error" pops up. The operation fails.
*Grabdiags are attached.

Steve Yen
added a comment - 27/Aug/12 5:17 PM Hi Abhinav,
Can you extend this jira bug with more reproduction steps info?
For example, were you using the web-based installation screen to load sample data?
Were you using the command-line tool? If so, what was the command-line?
And, what was your bucket configuration?
What O/S or environment was this? (e.g, linux? windows?)
(p.s., in general, a good bug report will have enough, relevant reproduction info in it (e.g., signal, not too much noise.))
Thanks much!
Steve

So the error seems to be the following:
"/Applications/Couchbase Server.app/Contents/Resources/couchbase-core/bin/tools/cbdocloader: line 12: /Applications/Couchbase: No such file or directory\n/Applications/Couchbase Server.app/Contents/Resources/couchbase-core/bin/tools/cbdocloader: line 12: exec: /Applications/Couchbase: cannot execute: No such file or directory\n"

This could be because the space not being escaped in "Couchbase Server", it can also be fixed by enclosing the entire path with quotes.

Abhinav Dangeti
added a comment - 27/Aug/12 8:36 PM So the error seems to be the following:
"/Applications/Couchbase Server.app/Contents/Resources/couchbase-core/bin/tools/cbdocloader: line 12: /Applications/Couchbase: No such file or directory\n/Applications/Couchbase Server.app/Contents/Resources/couchbase-core/bin/tools/cbdocloader: line 12: exec: /Applications/Couchbase: cannot execute: No such file or directory\n"
This could be because the space not being escaped in "Couchbase Server", it can also be fixed by enclosing the entire path with quotes.

Jens Alfke
added a comment - 28/Aug/12 11:47 AM I fixed this issue in the wrapper script in membase-cli, but there are several other copies of this wrapper in other repos that need to be fixed too...
http://review.couchbase.org/#/c/20252/

Farshid Ghods (Inactive)
added a comment - 12/Sep/12 10:08 PM not sure if this is permission issue.
Abhinav,
this is different than the centos 5.x issue exists with cbdocloader.
can you try this latest build on your mac and see if its reproducible ?

Farshid Ghods (Inactive)
added a comment - 12/Sep/12 10:09 PM Matt,
what error do you get if you try to run cbdocloader manually from ~/Couchase Server.app/..../couchbase-core/bin/tools/ to load this sample data ?

this is not reproducible on new installations , so moving this to beta refresh as this could be happening if node already has previous version installed and user did not clean up the data folder entirely

Farshid Ghods (Inactive)
added a comment - 13/Sep/12 10:18 AM this is not reproducible on new installations , so moving this to beta refresh as this could be happening if node already has previous version installed and user did not clean up the data folder entirely

Bin Cui
added a comment - 14/Sep/12 11:36 AM Matt, can you manually remove /tmp/_working directory and try again?
For beta refresh, i will add logic to delete any existed tmp working directory before extracting zip files to working directory.

I and Bin have tried this on multiple mac and eventually found one Mac box that has this issue.

the issue is not related to /tmp or the other temp folder that python obtains as part of the its request but mostly about the permissions that the application seems to have when it starts for the first time.

upon restarting the app we were able to load the data.

bin is currently looking into this issue but as i mentioned this is only mac specific

Farshid Ghods (Inactive)
added a comment - 14/Sep/12 5:39 PM I and Bin have tried this on multiple mac and eventually found one Mac box that has this issue.
the issue is not related to /tmp or the other temp folder that python obtains as part of the its request but mostly about the permissions that the application seems to have when it starts for the first time.
upon restarting the app we were able to load the data.
bin is currently looking into this issue but as i mentioned this is only mac specific

The specific Python exception:
IOError: [Errno 20] Not a directory: '/tmp/_working/beer-sample/design_docs'
This is ENOTDIR. Implies that some component of that path is a file not a directory.

Also interesting is that the logs above show that cbdocloader is writing into /tmp, while when I call the same Python API that cbdocloader does — tempfile.gettempdir() — I get a per-user temp directory (/var/folders/4f/mvdftm3d5ss0ystm0m2q8q3m0000gn/T).

This may correlate to the OS version. I don't see any details above of what exactly OS version was running, but the logs refer to Python 2.6, which I believe appeared in OS X 10.6. (I'm on 10.8 which has Python 2.7.2, and IIRC 10.7 had an earlier Python 2.7 release.)

Jens Alfke
added a comment - 14/Sep/12 7:17 PM The specific Python exception:
IOError: [Errno 20] Not a directory: '/tmp/_working/beer-sample/design_docs'
This is ENOTDIR. Implies that some component of that path is a file not a directory.
Also interesting is that the logs above show that cbdocloader is writing into /tmp, while when I call the same Python API that cbdocloader does — tempfile.gettempdir() — I get a per-user temp directory (/var/folders/4f/mvdftm3d5ss0ystm0m2q8q3m0000gn/T).
This may correlate to the OS version. I don't see any details above of what exactly OS version was running, but the logs refer to Python 2.6, which I believe appeared in OS X 10.6. (I'm on 10.8 which has Python 2.7.2, and IIRC 10.7 had an earlier Python 2.7 release.)

1. This code will fail during the zip extraction with ENOTDIR if _working already exists in tmpdir but is a file not a directory. That might actually be the cause of this bug, but I have no idea where the _working file might come from. (But note that this temp dir is shared by all processes belonging to that user, and "_working" is a pretty generic name, so it could be any other process/app creating it.)
2. The test-then-create sequence is a filesystem race condition. There's a chance the _working dir could have existed but been deleted in between the two os calls. This kind of issue has led to security holes in the past. It's safer to always call os.makedirs and then ignore a duplicate-file (EEXIST) error.
3. The exception handler effectively ignores the exception. It skips unzipping the file, but the caller has no idea anything went wrong, so it's likely to break. It's probably best to not catch the exception at all but let it propagate to the top level where it can be reported.
4. If _working already exists, shouldn't it be deleted instead of reused? It might contain unrelated files that will get mixed in with the files from the zip archive.
5. As I mentioned above, "_working" is a generic name, and since this is a temp dir used by other processes, it should be something more specific like "cbdocloader_working".

Jens Alfke
added a comment - 14/Sep/12 7:27 PM There are several problems with the function in cbdocloader that ends up throwing the exception. I don't know if they're causing this bug, but they're worth pointing out:
working_dir = os.path.join(tmpdir, '_working')
if not os.path.exists(working_dir):
try:
os.makedirs(working_dir)
except:
print "Unexpected error:", sys.exc_info() [0]
return
1. This code will fail during the zip extraction with ENOTDIR if _working already exists in tmpdir but is a file not a directory. That might actually be the cause of this bug, but I have no idea where the _working file might come from. (But note that this temp dir is shared by all processes belonging to that user, and "_working" is a pretty generic name, so it could be any other process/app creating it.)
2. The test-then-create sequence is a filesystem race condition. There's a chance the _working dir could have existed but been deleted in between the two os calls. This kind of issue has led to security holes in the past. It's safer to always call os.makedirs and then ignore a duplicate-file (EEXIST) error.
3. The exception handler effectively ignores the exception. It skips unzipping the file, but the caller has no idea anything went wrong, so it's likely to break. It's probably best to not catch the exception at all but let it propagate to the top level where it can be reported.
4. If _working already exists, shouldn't it be deleted instead of reused? It might contain unrelated files that will get mixed in with the files from the zip archive.
5. As I mentioned above, "_working" is a generic name, and since this is a temp dir used by other processes, it should be something more specific like "cbdocloader_working".

1. This code will fail during the zip extraction with ENOTDIR if _working already exists in tmpdir but is a file not a directory. That might actually be the cause of this bug, but I have no idea where the _working file might come from. (But note that this temp dir is shared by all processes belonging to that user, and "_working" is a pretty generic name, so it could be any other process/app creating it.) 2. The test-then-create sequence is a filesystem race condition. There's a chance the _working dir could have existed but been deleted in between the two os calls. This kind of issue has led to security holes in the past. It's safer to always call os.makedirs and then ignore a duplicate-file (EEXIST) error.
3. The exception handler effectively ignores the exception. It skips unzipping the file, but the caller has no idea anything went wrong, so it's likely to break. It's probably best to not catch the exception at all but let it propagate to the top level where it can be reported.
4. If _working already exists, shouldn't it be deleted instead of reused? It might contain unrelated files that will get mixed in with the files from the zip archive.
5. As I mentioned above, "_working" is a generic name, and since this is a temp dir used by other processes, it should be something more specific like "cbdocloader_working".

Bin Cui
added a comment - 15/Sep/12 8:36 AM There are several problems with the function in cbdocloader that ends up throwing the exception. I don't know if they're causing this bug, but they're worth pointing out:
working_dir = os.path.join(tmpdir, '_working')
if not os.path.exists(working_dir):
try:
os.makedirs(working_dir)
except:
print "Unexpected error:", sys.exc_info() [0]
return
Jens Alfke commented on MB-6452 :
--------------------------------
1. This code will fail during the zip extraction with ENOTDIR if _working already exists in tmpdir but is a file not a directory. That might actually be the cause of this bug, but I have no idea where the _working file might come from. (But note that this temp dir is shared by all processes belonging to that user, and "_working" is a pretty generic name, so it could be any other process/app creating it.) 2. The test-then-create sequence is a filesystem race condition. There's a chance the _working dir could have existed but been deleted in between the two os calls. This kind of issue has led to security holes in the past. It's safer to always call os.makedirs and then ignore a duplicate-file (EEXIST) error.
3. The exception handler effectively ignores the exception. It skips unzipping the file, but the caller has no idea anything went wrong, so it's likely to break. It's probably best to not catch the exception at all but let it propagate to the top level where it can be reported.
4. If _working already exists, shouldn't it be deleted instead of reused? It might contain unrelated files that will get mixed in with the files from the zip archive.
5. As I mentioned above, "_working" is a generic name, and since this is a temp dir used by other processes, it should be something more specific like "cbdocloader_working".