Clojurians Log v2

Check server logs to make sure it's a server issue. https://clojure-lsp.io/troubleshooting/#server-log

are you on a recent version? i think clojure-lsp just had some major performance improvements. maybe you need to clear cache and try again?

> 2026-07-28T18:15:41.858Z INFO [clojure-lsp.startup:151] - :internal/copy-kondo-configs 211866ms that feels... suspicious

I have only one dependency in this project, and it's datascript

so I guess I go look at that

wait

> 2026-07-28T18:15:41.857Z WARN [clojure-lsp.kondo:374] - [clj-kondo] No configs copied. > 2026-07-28T18:15:41.858Z INFO [clojure-lsp.startup:151] - :internal/copy-kondo-configs 211866ms

so just before the line where it took several minutes to copy configs, it says no configs were copied?

did you try clearing your clj-kondo cache as well? rm -rf .clj-kondo/.cache .lsp/.cache?

I'll give that a shot now

I'll note by the way that this is project dependant

I will try to make a minimal reproduction case.

I have another project where it starts just fine

Ok, well clearing the cache did not help

I... have yet to figure out what a minimal reproduction case is

ok, well I just copied my flake.nix, flake.lock, deps.edn, and the one namespace that I had from the non-working version

and it works...

so there is something else in the environment that I cannot identify that was breaking it.

i wonder if its possible to initialize lsp in the project without the lsp client so there’s no timeout. then the cache will be correctly populated

good call, something like $ clojure-lsp diagnostics and then after that runs, open your editor?

I tried that and it did not work

hmmmmmmmmmmmmm

clojure-lsp diagnostics will full cache and editor should pick it up, so if that's not helping the problem must be elsewhere, weird copy kondo configs take that much

what's the dependency?

oh you said you copied it and it didn't repro

Is it possible that there's something very large in this project that's being scanned by kondo? For instance, it could be an NFS accident that created huge files, or some large jar file on in classpath, etc... It might be useful to check which processes are running during the initialization

it's a fresh repo

How about the processes running during the 5 minutes to timeout? If this is unix, just using top might be good enough to check out what's going on, and maybe ps auxww --forest to more easily see the parentage of processes. I was wondering if both kondo and clojure-lsp are running during this time or if it's just something internal to clojure-lsp in which case you should only see kondo for a few seconds while it scans

Also, it could be nice to know for sure that this is all initialization - does the log have 5 minutes for :lsp/initialize? (eg mine is 11 seconds)

INFO [clojure-lsp.handlers:170] - :lsp/initialize 11444ms

When I looked at top when it was taking time to time out, it was just clojure-lsp taking 99% of one cpu and no other notable processes going.

as for initialize time, it never gets to the initialization completing, even when I increase timeout to 15 minutes.

so I never see that log message

actually, looks like on the 15 minute timeout I did get it:

2026-07-28T19:12:51.692Z  INFO [clojure-lsp.handlers:170] - :lsp/initialize 858422ms

Wow, that's like 14 minutes?!

yep

I don't understand what in the environment could be causing it since it was a fresh repo with 2 commits and a namespace that does nothing except require its exactly one dependency

I can share the repo a little later and see if anyone else can reproduce the issue

Are there other large timing numbers is in log file?

honestly part of me wonders if pushing it to a forge then doing a fresh clone will resolve it

I was wondering if it has something to do with the filesystem it's on... like for some reason accessing one file there is really slow for some reason

yes, there's other large ones, let me share them

2026-07-28T19:02:02.365Z  INFO [clojure-lsp.startup:151] - :internal/copy-kondo-configs 209052ms
2026-07-28T19:09:06.264Z  INFO [clojure-lsp.startup:136] - :internal/external-classpath-analysis 423899ms
2026-07-28T19:12:51.688Z  INFO [clojure-lsp.startup:73] - :internal/project-paths-analyzed-by-clj-kondo 225381ms
2026-07-28T19:12:51.692Z  INFO [clojure-lsp.handlers:170] - :lsp/initialize 858422ms
2026-07-28T19:12:52.299Z  INFO [clojure-lsp.feature.clojuredocs:21] - :internal/refresh-clojuredocs-cache 607ms
2026-07-28T19:12:55.588Z  INFO [clojure-lsp.db:83] - :db/read-cache 3278ms

these were all the ones that were over 2 digit ms

When you say "fresh repo with 2 commits", do you mean git init and then two commits with clj files + there's a dependency? Or a large repo with two additional commits?

I mean it's git init, an empty commit with --allow-empty (so I can rebase off it), and then a single commit that adds a nix flake to add clojure-lsp and clojure to my local environment, as well as a deps.edn that pulls in clojure 1.12.5 and datascript, and a single ns that requires datascript with no other code

{:paths ["src"]
 :deps {org.clojure/clojure {:mvn/version "1.12.5"}
        datascript/datascript {:mvn/version "1.7.8"}}

 :aliases
 {:dev {:extra-paths ["." "dev"]
        :extra-deps {;; Profiling and insight tools
                     criterium/criterium {:mvn/version "0.4.6"}}}}}

what happens if you remove "." from the :dev path?

uhh; that seems to do it

🎉

I mean; breaking on including "." in the paths seems pretty bad since that's now standard practice with tools.build

it's scanning all of the git/etc files

But I am glad to find out what was causing the trouble

I wonder if it was also scanning its own cache

I wonder if we should add logging for all of external processes that are executed? Would that have made it quicker to find the root of this problem?

I like that

I added a little PR (https://github.com/clojure-lsp/clojure-lsp/pull/2438) to get a little extra logging of times. It's sort of a poor man's profiling for initialization. We could probably do better/more, but this might be enough for now.