Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Bisq fails to start because of data directory issue #3998

Closed
ripcurlx opened this issue Feb 21, 2020 · 4 comments · Fixed by #4002
Closed

Bisq fails to start because of data directory issue #3998

ripcurlx opened this issue Feb 21, 2020 · 4 comments · Fixed by #4002
Assignees
@cbeams
Labels
a:bug is:critical https://bisq.wiki/Critical_bug is:priority PR or issue marked with this label is up for compensation on:Linux on:Windows waiting for author

Comments

@ripcurlx
Copy link
Contributor

Description

Based on https://bisq.community/t/new-install-not-starting-up/8963/25

Users cannot start version v1.2.7 because of following exception being thrown:

$ /opt/Bisq/Bisq
error: Application data directory '/home/xxx/.local/share/Bisq' could not be created

Version

Regression bug affecting version v1.2.7.
Does work in v1.2.5.

Steps to reproduce

Unfortunately not 100% clear why this is happening.
Every time this users start v1.2.7 with an existing data directory the app fails to start.
Reverting back to v1.2.5 solves the problem and app starts as expected.

Expected behaviour

App starts.

Actual behaviour

App fails to start.

Device or machine

We know about one affected user on Windows and one on Linux.
@ripcurlx ripcurlx added on:Windows on:Linux is:priority PR or issue marked with this label is up for compensation is:critical https://bisq.wiki/Critical_bug labels Feb 21, 2020
cbeams added a commit to cbeams/bisq that referenced this issue Feb 24, 2020
@cbeams
Throw UncheckedIOException on directory creation errors
f17c7df 
Previously, Config#mkdir and #mkAppDir threw ConfigException if any
underlying IOException was thrown from Files#createDirectory or
Files#createDirectories respectively. This resulted in only a simple
error message being reported at the command line and the details of the
underlying exception's stack trace were lost. This change wraps and
rethrows the underlying IOException as an UncheckedIOException such that
it gets caught by the catch(Throwable) clause in BisqExecutable, which
does print a stacktrace to stderr. This is the way it always should have
worked; throwing ConfigException in these cases was an oversight in the
original implementation. This change also removes the ConfigException
constructor that allows for passing a nested exception to be wrapped as
there is actually no use case for this now that these two anomalies have
been corrected.

This change was made in the process of attempting to reproduce bisq-network#3998.
@cbeams
Copy link
Contributor

cbeams commented Feb 24, 2020

The following comment is cross-posted from https://bisq.community/t/new-install-not-starting-up/8963/31:

I have been unable to reproduce this error. Here are the steps I took:

  1. Install a fresh Ubuntu 18.04.4 LTS VM via VirtualBox
  2. Download and install the Bisq v1.2.5 .deb from https://github.com/bisq-network/bisq/releases/tag/v1.2.5
  3. Run Bisq successfully with no command line options
  4. Notice that the app starts up without error
  5. Inspect ~/.local/share/Bisq and notice that everything is in place as it should be
  6. Click the link within the running Bisq application to download and verify the v1.2.7 release
  7. Close Bisq v1.2.5, install and run the newly-downloaded v1.2.7 .deb.
  8. Notice that the app starts up without error
  9. Inspect the ~/.local/share/Bisq directory and the contents of the bisq.log file within and notice that everything is as it should be.

Since I cannot reproduce this myself, what's needed now is to get more information about the reason for the failure to create the (already existing) ~/.local/share/Bisq directory. I've just published a patch that will ensure a stack trace is printed to the console in the case of this kind of directory creation failure. @tieck and/or @DrFredPhD, could one of you build and run from source using the following commands and report the stack trace back here?

First you will need to have JDK 10, 11 or 12 installed locally. Use JDK 10 if you don't have anything installed already. You can get it from https://jdk.java.net/. When complete, check your java version at the command line and you should see the following:

$ java -version
openjdk version "10.0.2" 2018-07-17
OpenJDK Runtime Environment 18.3 (build 10.0.2+13)
OpenJDK 64-Bit Server VM 18.3 (build 10.0.2+13, mixed mode)

Next, you need to build and run Bisq with my patch applied. Here's how to do it if you have git installed. If you don't, see the alternative instructions that follow:

git clone --depth=50 --branch=debug-appdir-creation https://github.com/cbeams/bisq
cd bisq
./gradlew :desktop:run

If you do not have git installed, you can download the source as a zip file, unzip it and run the ./gradlew :desktop:run command within the bisq directory it unzips into:

  1. Download and unzip https://github.com/cbeams/bisq/archive/debug-appdir-creation.zip
  2. cd bisq
  3. ./gradlew :desktop:run

Note that on Windows, you will need to run gradlew.bat :desktop:run instead of ./gradlew :desktop:run

You should end up with an error that begins with the following lines:

> Task :desktop:run FAILED
fault: An unexpected error occurred. Please file a report at https://bisq.network/issues
...

Please copy and paste your entire error message here.

cbeams added a commit to cbeams/bisq that referenced this issue Feb 24, 2020
@cbeams
Throw UncheckedIOException on directory creation errors
f5ca539 
Previously, Config#mkdir and #mkAppDir threw ConfigException if any
underlying IOException was thrown from Files#createDirectory or
Files#createDirectories respectively. This resulted in only a simple
error message being reported at the command line and the details of the
underlying exception's stack trace were lost. This change wraps and
rethrows the underlying IOException as an UncheckedIOException such that
it gets caught by the catch(Throwable) clause in BisqExecutable, which
does print a stacktrace to stderr. This is the way it always should have
worked; throwing ConfigException in these cases was an oversight in the
original implementation. This change also removes the ConfigException
constructor that allows for passing a nested exception to be wrapped as
there is actually no use case for this now that these two anomalies have
been corrected.

This change was made in the process of attempting to reproduce bisq-network#3998.
@cbeams cbeams mentioned this issue Feb 24, 2020
Merged
cbeams added a commit to cbeams/bisq that referenced this issue Feb 24, 2020
@cbeams
Throw UncheckedIOException on directory creation errors
de537f0 
Previously, Config#mkdir and #mkAppDir threw ConfigException if any
underlying IOException was thrown from Files#createDirectory or
Files#createDirectories respectively. This resulted in only a simple
error message being reported at the command line and the details of the
underlying exception's stack trace were lost. This change wraps and
rethrows the underlying IOException as an UncheckedIOException such that
it gets caught by the catch(Throwable) clause in BisqExecutable, which
does print a stacktrace to stderr. This is the way it always should have
worked; throwing ConfigException in these cases was an oversight in the
original implementation. This change also removes the ConfigException
constructor that allows for passing a nested exception to be wrapped as
there is actually no use case for this now that these two anomalies have
been corrected.

This change was made in the process of attempting to reproduce bisq-network#3998.
@cbeams
Copy link
Contributor

cbeams commented Feb 25, 2020

@tieck wrote via https://bisq.community/t/new-install-not-starting-up/8963/32:

It seems that the new version does not handle symbolic links in the path of the Bisq application directory the same way anymore.

I could reproduce the behavior in first moving away the application directory and then creating a symbolic link at its place:

$ mkdir ~/tmp
$ mv ~/.local/share/Bisq/ ~/tmp
$ ln -s ~/tmp/Bisq/ ~/.local/share/Bisq
$ ./gradlew :desktop:run

> Task :desktop:run FAILED
fault: An unexpected error occurred. Please file a report at https://bisq.network/issues
java.io.UncheckedIOException: Application data directory '/home/xxx/.local/share/Bisq' could not be created
        at bisq.common.config.Config.mkAppDataDir(Config.java:805)
        at bisq.common.config.Config.<init>(Config.java:644)
    at bisq.core.app.BisqExecutable.execute(BisqExecutable.java:76)
    at bisq.desktop.app.BisqAppMain.main(BisqAppMain.java:57)
Caused by: java.nio.file.FileAlreadyExistsException: /home/xxx/.local/share/Bisq
    at java.base/sun.nio.fs.UnixException.translateToIOException(UnixException.java:94)
    at java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:111)
    at java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:116)
    at java.base/sun.nio.fs.UnixFileSystemProvider.createDirectory(UnixFileSystemProvider.java:385)
    at java.base/java.nio.file.Files.createDirectory(Files.java:689)
    at java.base/java.nio.file.Files.createAndCheckIsDirectory(Files.java:796)
    at java.base/java.nio.file.Files.createDirectories(Files.java:742)
    at bisq.common.config.Config.mkAppDataDir(Config.java:803)
    ... 3 more

cbeams added a commit to cbeams/bisq that referenced this issue Feb 25, 2020
@cbeams
Do not attempt to create already existing appDataDir
cbe6f19 
This change fixes bisq-network#3998 by avoiding the attempt to create a user's
appDataDir if it already exists. Normally this attempt is not a problem,
as Files#createDirectories does nothing if the target is a directory
that already exists, but in the case that the target is a symbolic link,
Files#createDirectories throws a FileAlreadyExistsException. This change
prevents the call to Files#createDirectories if the target already
exists, and if in fact the target is a symbolic link pointing to an
existing directory, this is not a problem and everything proceeds as per
usual. This mimics the behavior in Bisq v1.2.5 and prior, where
File#mkdirs was used instead of Files#createDirectories. File#mkdirs
does not throw an exception when the target directory is a symlink, it
just returns false.
@DrFredPhD
Copy link

DrFredPhD commented Feb 25, 2020 via email

@cbeams
Copy link
Contributor

cbeams commented Feb 25, 2020

Perfect timing, @DrFredPhD. I've just submitted PR #4002, which fixes this problem. Thanks for getting back.

@cbeams cbeams added the a:bug label Feb 27, 2020
@ripcurlx ripcurlx mentioned this issue Mar 16, 2020
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@cbeams cbeams

Labels
a:bug is:critical https://bisq.wiki/Critical_bug is:priority PR or issue marked with this label is up for compensation on:Linux on:Windows waiting for author
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Avoid startup failure when appDataDir is a symbolic link cbeams/bisq
3 participants
@ripcurlx @cbeams @DrFredPhD