Every time I launch IntelliJ 2024.1 with codegpt installed, an error regarding inotify is logged.

[fallingrock]

What happened?

Every time I launch IntelliJ 2024.1 with codegpt installed, an error regarding inotify is logged.

IntelliJ IDEA 2024.1 (Ultimate Edition)
Build #IU-241.14494.240, built on March 28, 2024
Licensed to xxxx
Subscription is active until xxxxx.
Runtime version: 17.0.10+8-b1207.12 amd64
VM: OpenJDK 64-Bit Server VM by JetBrains s.r.o.
Linux 6.5.0-28-generic
GC: G1 Young Generation, G1 Old Generation
Memory: 2048M
Cores: 20
Registry:
ide.experimental.ui=true
Non-Bundled Plugins:
com.jetbrains.plugins.ini4idea (241.14494.240)
com.guohanlin.JsonToJava (2023.1.3)
bundled-intellij-idea-help (241.14494.240)
org.jetbrains.jumpToLine (0.1.15)
ink.organics.pojo2json (2.0.6)
com.jetbrains.jax.ws (241.14494.158)
jd-intellij (0.8.1)
com.intellij.properties.bundle.editor (241.14494.150)
com.intellij.spring.websocket (241.14494.158)
com.intellij.editSuggestion (241.14494.158)
ee.carlrobert.chatgpt (2.6.3-241)
Pythonid (241.14494.314)
com.intellij.laf.macos (241.14494.150)
com.intellij.grazie.pro (0.3.300)
com.intellij.ml.llm (241.14494.320)
com.jetbrains.packagesearch.intellij-plugin (241.0.9)
org.jetbrains.android (241.14494.240)
com.android.tools.design (241.14494.158)
androidx.compose.plugins.idea (241.14494.158)
com.intellij.queryComplexity (241.14494.150)
com.intellij.spring.ws (241.14494.158)
org.sonarlint.idea (10.4.2.78113)
com.intellij.java.rareRefactorings (241.14494.158)
Kotlin: 241.14494.240-IJ
Current Desktop: KDE

Relevant log output or stack trace

Unhandled exception in [ComponentManager(ProjectImpl@245312888), CoroutineName(run activity), run activity, StandaloneCoroutine{Cancelling}@32df9e9a, Dispatchers.Default]

java.io.IOException: User limit of inotify instances reached or too many open files
	at java.base/sun.nio.fs.LinuxWatchService.<init>(LinuxWatchService.java:62)
	at java.base/sun.nio.fs.LinuxFileSystem.newWatchService(LinuxFileSystem.java:47)
	at ee.carlrobert.codegpt.FileWatcher.watch(FileWatcher.kt:18)
	at ee.carlrobert.codegpt.CodeGPTProjectActivity.execute(CodeGPTProjectActivity.kt:43)
	at com.intellij.ide.startup.impl.StartupManagerImplKt$launchActivity$1.invokeSuspend(StartupManagerImpl.kt:473)
	at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:33)
	at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:108)
	at kotlinx.coroutines.scheduling.CoroutineScheduler.runSafely(CoroutineScheduler.kt:584)
	at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.executeTask(CoroutineScheduler.kt:793)
	at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.runWorker(CoroutineScheduler.kt:697)
	at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.run(CoroutineScheduler.kt:684)
	Suppressed: kotlinx.coroutines.internal.DiagnosticCoroutineContextException: [ComponentManager(ProjectImpl@245312888), CoroutineName(run activity), run activity, StandaloneCoroutine{Cancelled}@32df9e9a, Dispatchers.Default]

Steps to reproduce

No response

CodeGPT version

2.6.3-241

Operating System

Linux

[sisve]

This seems related to the recent changes to watching for file changes. Can you give us any estimate on the size of the project Could you check your current number of allowed inotify instances with cat /proc/sys/fs/inotify/max_user_instances?

A guess at a temporary workaround is to increase that number using echo higher_number_here | sudo tee /proc/sys/fs/inotify/max_user_instances. Changing the number this way will see it reset at every reboot.

Can you test increasing the number of inotify instances allowed, and see if that solves the problem?

[reneleonhardt]

Thank you for reporting, glad to see a Linux user! Can you check your current setting and increase it?
https://stackoverflow.com/questions/32281277/too-many-open-files-failed-to-initialize-inotify-the-user-limit-on-the-total#answer-38486048
If you don't need the FileWatcher you can disable it (enabled by default):
Settings | Tools | CodeGPT | Configuration: Check for new screenshots automatically
I'm wondering if Java would detect your home directory correctly... System.getProperty("user.home") 🤔

[fallingrock]

Here's the inotify values as reported by sysctl:
user.max_inotify_instances = 128
user.max_inotify_watches = 104857

When you ask about the size of the project, are you talking about source files?

After disabling the filewatcher, it appears that the error is no longer appearing.

However, when I launch a local instance of LLaMA c/c++ usin a pre-defined model, I get "Request timed out. This may be due to the server being overloaded." when I ask it to explain some highlighted code.

No clue if the two issues are related.

[reneleonhardt]

Do you have a screenshot, is there an exception stacktrace in the log?
I don't think they are related, you probably chose a model which is "too big" for your machine.
You could try one with a smaller download size, they are usually faster, for example Code Llama 7B 4-bit precision.

[fallingrock]

My laptop is relatively powerful ... i7 w/ 10 cores & 32gb ram.

IIRC, the local server worked before.

Which log are you referring to?

llama.cpp/llama.log just has this ...
[1713906704] warming up the model with an empty run

The idea log has this timeout error when I ask the plug-in to explain a section of code:
2024-04-23 16:18:04,909 [2705768] SEVERE - #ee.carlrobert.codegpt.toolwindow.chat.ToolWindowCompletionResponseEventListener - Request timed out. This may be due to the server being overloaded. java.net.SocketTimeoutException: timeout at okio.SocketAsyncTimeout.newTimeoutException(JvmOkio.kt:146) at okio.AsyncTimeout.access$newTimeoutException(AsyncTimeout.kt:186) at okio.AsyncTimeout$source$1.read(AsyncTimeout.kt:390) at okio.RealBufferedSource.request(RealBufferedSource.kt:210) at okio.RealBufferedSource.require(RealBufferedSource.kt:203) at okio.RealBufferedSource.readHexadecimalUnsignedLong(RealBufferedSource.kt:388) at okhttp3.internal.http1.Http1ExchangeCodec$ChunkedSource.readChunkSize(Http1ExchangeCodec.kt:437) at okhttp3.internal.http1.Http1ExchangeCodec$ChunkedSource.read(Http1ExchangeCodec.kt:416) at okhttp3.internal.connection.Exchange$ResponseBodySource.read(Exchange.kt:281) at okio.RealBufferedSource.select(RealBufferedSource.kt:233) at okhttp3.internal.sse.ServerSentEventReader.processNextEvent(ServerSentEventReader.kt:50) at okhttp3.internal.sse.RealEventSource.processResponse(RealEventSource.kt:75) at okhttp3.internal.sse.RealEventSource.onResponse(RealEventSource.kt:46) at okhttp3.internal.connection.RealCall$AsyncCall.run(RealCall.kt:519) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) at java.base/java.lang.Thread.run(Thread.java:840) Caused by: java.net.SocketException: Socket closed at java.base/sun.nio.ch.NioSocketImpl.endRead(NioSocketImpl.java:253) at java.base/sun.nio.ch.NioSocketImpl.implRead(NioSocketImpl.java:332) at java.base/sun.nio.ch.NioSocketImpl.read(NioSocketImpl.java:355) at java.base/sun.nio.ch.NioSocketImpl$1.read(NioSocketImpl.java:808) at java.base/java.net.Socket$SocketInputStream.read(Socket.java:966) at okio.InputStreamSource.read(JvmOkio.kt:93) at okio.AsyncTimeout$source$1.read(AsyncTimeout.kt:153) ... 14 more

There is nothing additional logged to llama.log.

[fallingrock]

I'm playing around with the timeout values in the advanced settings.

Looks like it may be the fix.