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 confirmed that the problem was taking place because the app started generating the following in the logs (besides being irresponsive):
: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:
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
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?
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.
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:
I created a new user on my system to be sure not to have any previous Logseq config
I downloaded the zip in my clean home and extracted it there
I run Logseq binary with ./Logseq in a terminal emulator
Logseq starts normally
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.
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.
