On linux stop logreq from scanning '/' when it first starts (new install)

When a new installation is performed on Linux, after unzipping logseq to the desired destination directory, I noticed that when first launched, it will start scanning all my filesystems (local and nfs ones, and trigger the automounts too). This has, at least to me, a set of implications:

  • Unauthorized filesystem scanning
  • Scanning directories where I have millions of files causes logseq to be unresponsive
  • logseq will start failing due to the limit of watchers being reached - watcher appears to be per file.

On Linux at least, it would be nice to have a prompt for the directory to lock on without first starting the scan.

I don’t see why Logseq should scan all the drives, how did you check?

Also does this happen with the Flatpak version too?

Hello @alex0,

I installed it from the zip file:

:electron.handler/unwatch-dir {:path “/local”}
:electron.handler/watch-dir {:/path “/local”}
:electron.fs-watcher/on-error Watch error happened: {:path #object[Error Error: ENOSPC: System limit for number of file watchers reached, watch ‘/local/repos/media/00001002020.o’]}
:electron.fs-watcher/on-error Watch error happened: {:path #object[Error Error: ENOSPC: System limit for number of file watchers reached, watch ‘/local/repos/media/00001002220.o’]}
:electron.fs-watcher/on-error Watch error happened: {:path #object[Error Error: ENOSPC: System limit for number of file watchers reached, watch ‘/local/repos/media/00001002420.o’]}
:electron.fs-watcher/on-error Watch error happened: {:path #object[Error Error: ENOSPC: System limit for number of file watchers reached, watch ‘/local/repos/media/00001002520.o’]}
:electron.fs-watcher/on-error Watch error happened: {:path #object[Error Error: ENOSPC: System limit for number of file watchers reached, watch ‘/local/repos/media/00001002620.o’]}
:electron.fs-watcher/on-error Watch error happened: {:path #object[Error Error: ENOSPC: System limit for number of file watchers reached, watch ‘/local/repos/media/00001002720.o’]}
:electron.fs-watcher/on-error Watch error happened: {:path #object[Error Error: ENOSPC: System limit for number of file watchers reached, watch ‘/local/repos/media/00001002820.o’]}
:electron.fs-watcher/on-error Watch error happened: {:path #object[Error Error: ENOSPC: System limit for number of file watchers reached, watch ‘/local/repos/media/00001002920.o’]}

The only way to shut down the app was by killing the process, the app was nonresponsive. The only way I was able to circumvent this problem was by going to a different Linux computer (no network drives, and a small footprint - and configuring the app to use a given graph directory. - Then I copied the directories:

  • ~/.logseq
  • ~/.config/.Logseq
  • ~/mylogseq-graph-dir

Once this was done, the app no longer attempted to start by looking at local. the messages changed to be as follows:

:electron.handler/unwatch-dir {:path “/home/user1//mylogseq-graph-dir”}
:electron.handler/watch-dir {:/path"/home/user1//mylogseq-graph-dir"}

Interestingly enough - copying the config directories, which I thought would suffice to alleviate the problem was not enough.

  • ~/.logseq
  • ~/.config/.Logseq

Lastly, I tried a bunch of configuration changes to the edn files - but there seem to be at least 3 copies of the config.edn files - and non of the changes appear to affect the behavior of the application with respect to insisting to scan my filesystem:

  • ~/.logseq/config/config.edn
  • ~/.config/Logseq/configs.edn
  • ~/mylogseq-graph-dir/logseq/config.edn

I have not gotten around to all the documentation to understand what each of these files is for yet :frowning:

I can’t reproduce, it should look for /home/username/path/to/graph for each graph you have, not /local.

How did you “install” it? To which folder did you move the binary? Does this happen also if you run the binary just after extraction of the zip in your home, without moving the binary somewhere else? Does this happens also with the Flatpak and AppImage versions?

Hello @alex0

On both systems, the binary was at the same place: /softlib/logseq. The extraction was simply to do an unzip. The same thought crossed my mind, thinking that if I moved the binary from ‘/’ filesystem to the ‘/home’ filesystem, might make the difference, but the fact that both systems were installed identically made me doubt on this fact.

Based on your last reply, you state:

it should look for /home/username/path/to/graph for each graph you have, not /local.

Remember that my complaint is that when the app first starts, after a brand new install, there were no graphs defined. Also, when I launch the app, I do it from the shell prompt and not from an icon on the desktop. When you tried to reproduce it, are you also launching it from the shell prompt so you may observe the log messages it generates to stdout? Are you launching it from a brand new (no logseq installed before) system?

Yes and the messages tell it is looking for the graph folders.

If you mean that you created a folder under your root / and placed the binary there, that is a very odd thing to do. On Linux systems you can’t “install” applications this way. There are standard folders and a system of permissions and security measures when binaries are involved.

Please reply to my questions i.e. try to run Logseq in “normal” conditions without this odd “installation”: try with Flatpak (the standard way to install third party apps on a Linux desktop system), with AppImage and by just extracting the zip in your home and running it from there.

If those methods fail, then your odd installation method cannot be blamed.

Hello @alex0,

The installation is odd due to the nature of my current environment - regarding Flatpak - I am in a closed environment (there is no internet access) - so all files are copied via USB. logseq zip format is ideal for this sort of place.

Regarding unpacking in my home directory the application and trying to run it from there - I recall, now (after several iterations) that I tried that too, suspecting that the app may look at its mounted file system - that was not the case either.

Regardless of what mode of installation I followed, by original question remains, why is logseq scanning or looking for files, when the install unzip is brand new - there should not be any attempt to scan for files to watch without any prior configuration in place, don’t you agree?

What about AppImage? It’s supposed to be a portable format.

Are you booting a Linux distribution from a live USB? Otherwise I am not understanding your setup…

I would of it actually was the case… but I can’t reproduce the issue and since you have a peculiar setup, isn’t it reasonable to assume it is related?

This is how I tried to reproduce the issue:

  1. I created a new user on my system to be sure not to have any previous Logseq config
  2. I downloaded the zip in my clean home and extracted it there
  3. I run Logseq binary with ./Logseq in a terminal emulator
  4. Logseq starts normally
  5. In the terminal there are a few lines, in particular three of them mention:
    • watch-dir /home/test/.logseq/config
    • unwatch-dir /local
    • watch-dir /local

I don’t know what exactly they mean but it is not scanning / for sure.

I don’t see why Logseq should scan all your folders when run for the first time. You didn’t provide evidence it is doing so and the errors you shared don’t say that from what I can tell. If it is really scanning all your folders, I suppose something from your setup is triggering this behavior. For sure this shouldn’t be a feature request.

I think you should first of all try to run Logseq in normal conditions with your distro of choice, then perform the changes you need and see where it breaks. Then eventually ask for help pointing out your peculiar setup and the problem (i.e Logseq not running properly, don’t make assumptions like it scanning /).

I will move this thread in the category for help, please consider editing the title and the description with proper details after some investigations or mark it as answered and open a new thread if you prefer. :slight_smile:

@alex0,

Thank you! - I see what is taking place now

I didn’t want to expose the true directories - my apologies, but it is the /local - these are automounted in my private world, and they just happen to host millions of files - this is where the problem really is taking place. The fact that it even tries to start ‘watch-dir’ on given directories…

I am sorry for having taken your time due to this oversight on my part.

1 Like