Uploaded image for project: 'Couchbase Server'
  1. Couchbase Server
  2. MB-6452

intermittent failure when loading sample data via setup wizard or the "setting" tab on mac when user starts couchbase server app for the first time due to some permission issues

    Details

      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.

      1. 127.0.0.1-8091-diag.txt.gz
        68 kB
        Abhinav Dangeti
      2. ns-diag-20120912194935.txt.gz
        272 kB
        Matt Ingenthron
      3. ns-diag-20120914002213.txt.gz
        280 kB
        Matt Ingenthron
      No reviews matched the request. Check your Options in the drop-down menu of this sections header.

        Activity

        Hide
        jens Jens Alfke added a comment -

        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".

        Show
        jens Jens Alfke added a comment - 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".
        Hide
        jens Jens Alfke added a comment -

        Farshid: re. your last comment, what was in /tmp/_working after that error occurred?

        Show
        jens Jens Alfke added a comment - Farshid: re. your last comment, what was in /tmp/_working after that error occurred?
        Hide
        farshid Farshid Ghods (Inactive) added a comment -

        beer-sample gamesim-sample
        macsvr-106-01:_working couchbase$ ls -alh
        total 0
        drwxr-xr-x 4 couchbase wheel 136B Sep 14 17:12 .
        drwxrwxrwt 8 root wheel 272B Sep 14 17:12 ..
        rw-rr- 1 couchbase wheel 0B Sep 14 17:12 beer-sample
        rw-rr- 1 couchbase wheel 0B Sep 14 14:59 gamesim-sample

        Show
        farshid Farshid Ghods (Inactive) added a comment - beer-sample gamesim-sample macsvr-106-01:_working couchbase$ ls -alh total 0 drwxr-xr-x 4 couchbase wheel 136B Sep 14 17:12 . drwxrwxrwt 8 root wheel 272B Sep 14 17:12 .. rw-r r - 1 couchbase wheel 0B Sep 14 17:12 beer-sample rw-r r - 1 couchbase wheel 0B Sep 14 14:59 gamesim-sample
        Show
        bcui Bin Cui (Inactive) added a comment - http://review.couchbase.org/#/c/20880/
        Hide
        bcui Bin Cui (Inactive) added a comment -

        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".

        Show
        bcui Bin Cui (Inactive) added a comment - 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".

          People

          • Assignee:
            bcui Bin Cui (Inactive)
            Reporter:
            abhinav Abhinav Dangeti
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Gerrit Reviews

              There are no open Gerrit changes