Viewing Che workspaces logs
This section describes how to view Che workspaces logs.
Viewing logs from language servers and debug adapters
Checking important logs
This section describes how to check important logs.
-
In the OpenShift web console, click Applications → Pods to see a list of all the active workspaces.
-
Click on the name of the running Pod where the workspace is running. The Pod screen contains the list of all containers with additional information.
-
Choose a container and click the container name.
The most important logs are the
theia-ide
container and the plug-ins container logs. -
On the container screen, navigate to the Logs section.
Detecting memory problems
This section describes how to detect memory problems related to a plug-in running out of memory. The following are the two most common problems related to a plug-in running out of memory:
- The plug-in container runs out of memory
-
This can happen during plug-in initialization when the container does not have enough RAM to execute the entrypoint of the image. The user can detect this in the logs of the plug-in container. In this case, the logs contain
OOMKilled
, which implies that the processes in the container requested more memory than is available in the container. - A process inside the container runs out of memory without the container noticing this
-
For example, the Java language server (Eclipse JDT Language Server, started by the vscode-java extension) throws an OutOfMemoryException. This can happen any time after the container is initialized, for example, when a plug-in starts a language server or when a process runs out of memory because of the size of the project it has to handle.
To detect this problem, check the logs of the primary process running in the container. For example, to check the log file of Eclipse JDT Language Server for details, see the relevant plug-in-specific sections.
Logging the client-server traffic for debug adapters
This section describes how to log the exchange between Che-Theia and a debug adapter into the Output view.
-
A debug session must be started for the Debug adapters option to appear in the list.
-
Click File → Settings and then open Preferences.
-
Expand the Debug section in the Preferences view.
-
Set the trace preference value to
true
(default isfalse
). -
All the communication events are now logged.
-
To watch these events, click View → Output and select Debug adapters from the drop-down list at the upper right corner of the Output view.
Viewing logs for Python
This section describes how to view logs for the Python language server.
-
Navigate to the Output view and select Python in the drop-down list.
Viewing logs for Go
This section describes how to view logs for the Go language server.
Finding the gopath
This section describes how to find where the GOPATH
variable points to.
-
Execute the
Go: Current GOPATH
command.
Viewing the Debug Console log for Go
This section describes how to view the log output from the Go debugger.
-
Set the
showLog
attribute totrue
in the debug configuration.{ "version": "0.2.0", "configurations": [ { "type": "go", "showLog": true .... } ] }
-
To enable debugging output for a component, add the package to the comma-separated list value of the
logOutput
attribute:{ "version": "0.2.0", "configurations": [ { "type": "go", "showLog": true, "logOutput": "debugger,rpc,gdbwire,lldbout,debuglineerr" .... } ] }
-
The debug console prints the additional information in the debug console.
Viewing logs for the NodeDebug NodeDebug2 adapter
No specific diagnostics exist other than the general ones. |
Viewing logs for Typescript
Enabling the label switched protocol (LSP) tracing
-
To enable the tracing of messages sent to the Typescript (TS) server, in the Preferences view, set the
typescript.tsserver.trace
attribute toverbose
. Use this to diagnose the TS server issues. -
To enable logging of the TS server to a file, set the
typescript.tsserver.log
attribute toverbose
. Use this log to diagnose the TS server issues. The log contains the file paths.
Viewing logs for Java
Other than the general diagnostics, there are Language Support for Java (Eclipse JDT Language Server) plug-in actions that the user can perform.
Verifying the state of the Eclipse JDT Language Server
Check if the container that is running the Eclipse JDT Language Server plug-in is running the Eclipse JDT Language Server main process.
-
Open a terminal in the container that is running the Eclipse JDT Language Server plug-in (an example name for the container:
vscode-javaxxx
). -
Inside the terminal, run the
ps aux | grep jdt
command to check if the Eclipse JDT Language Server process is running in the container. If the process is running, the output is:usr/lib/jvm/default-jvm/bin/java --add-modules=ALL-SYSTEM --add-opens java.base/java.util
This message also shows the VSCode Java extension used. If it is not running, the language server has not been started inside the container.
-
Check all logs described in Checking important logs
Verifying the Eclipse JDT Language Server features
If the Eclipse JDT Language Server process is running, check if the language server features are working:
-
Open a Java file and use the hover or autocomplete functionality. In case of an erroneous file, the user sees Java in the Outline view or in the Problems view.
Viewing the Java language server log
The Eclipse JDT Language Server has its own workspace where it logs errors, information about executed commands, and events.
-
To open this log file, open a terminal in the container that is running the Eclipse JDT Language Server plug-in. You can also view the log file by running the Java: Open Java Language Server log file command.
-
Run
cat <PATH_TO_LOG_FILE>
wherePATH_TO_LOG_FILE
is/home/theia/.theia/workspace-storage/<workspace_name>/redhat.java/jdt_ws/.metadata/.log
.
Logging the Java language server protocol (LSP) messages
To log the LSP messages to the VS Code Output view, enable tracing by setting the java.trace.server
attribute to verbose
.
For troubleshooting instructions, see the VS Code Java Github repository.
Viewing logs for Intelephense
Logging the Intelephense client-server communication
To configure the PHP Intelephense language support to log the client-server interexchange in the Output view:
-
Click File → Settings.
-
Open the Preferences view.
-
Expand the Intelephense section and set the
trace.server.verbose
preference value toverbose
to see all the communication events (the default value isoff
).
Viewing logs for PHP-Debug
This procedure describes how to configure the PHP Debug plug-in to log the PHP Debug plug-in diagnostic messages into the Debug Console view. Configure this before the start of the debug session.
-
In the
launch.json
file, add the"log": true
attribute to the selected launch configuration. -
Start the debug session.
-
The diagnostic messages are printed into the Debug Console view along with the application output.
Viewing logs for XML
Other than the general diagnostics, there are XML plug-in specific actions that the user can perform.
Verifying the state of the XML language server
-
Open a terminal in the container named
vscode-xml-<xxx>
. -
Run
ps aux | grep java
to verify that the XML language server has started. If the process is running, the output is:java ***/org.eclipse.ls4xml-uber.jar`
If is not, see the Checking important logs chapter.
Checking XML language server feature flags
-
Check if the features are enabled. The XML plug-in provides multiple settings that can enable and disable features:
-
xml.format.enabled
: Enable the formatter -
xml.validation.enabled
: Enable the validation -
xml.documentSymbols.enabled
: Enable the document symbols
-
-
To diagnose whether the XML language server is working, create a simple XML element, such as
<hello></hello>
, and confirm that it appears in the Outline panel on the right. -
If the document symbols do not show, ensure that the
xml.documentSymbols.enabled
attribute is set totrue
. If it istrue
, and there are no symbols, the language server may not be hooked to the editor. If there are document symbols, then the language server is connected to the editor. -
Ensure that the features that the user needs, are set to
true
in the settings (they are set totrue
by default). If any of the features are not working, or not working as expected, file an issue against the Language Server.
Viewing logs for YAML
This section describes the YAML plug-in specific actions that the user can perform, in addition to the general diagnostics ones.
Verifying the state of the YAML language server
This section describes how to verify the state of the YAML language server.
Check if the container running the YAML plug-in is running the YAML language server.
-
In the editor, open a terminal in the container that is running the YAML plug-in (an example name of the container:
vscode-yaml-<xxx>
). -
In the terminal, run the
ps aux | grep node
command. This command searches all the node processes running in the current container. -
Verify that a command
node **/server.js
is running.
The node **/server.js
running in the container indicates that the language server is running. If it is not running, the language server has not started inside the container. In this case, see Checking important logs.
Checking the YAML language server feature flags
To check the feature flags:
-
Check if the features are enabled. The YAML plug-in provides multiple settings that can enable and disable features, such as:
-
yaml.format.enable
: Enables the formatter -
yaml.validate
: Enables validation -
yaml.hover
: Enables the hover function -
yaml.completion
: Enables the completion function
-
-
To check if the plug-in is working, type the simplest YAML, such as
hello: world
, and then open the Outline panel on the right side of the editor. -
Verify if there are any document symbols. If yes, the language server is connected to the editor.
-
If any feature is not working, make sure that the settings listed above are set to
true
(they are set totrue
by default). If a feature is not working, file an issue against the Language Server.
Viewing logs for Dotnet with Omnisharp-Theia plug-in
Omnisharp-Theia plug-in
Che uses the Omnisharp-Theia plug-in as a remote plug-in. It is located at github.com/redhat-developer/omnisharp-theia-plugin. In case of an issue, report it, or contribute your fix in the repository.
This plug-in registers omnisharp-roslyn as a language server and provides project dependencies and language syntax for C# applications.
The language server runs on .NET SDK 2.2.105.
Verifying the state of the Omnisharp-Theia plug-in language server
To check if the container running the Omnisharp-Theia plug-in is running OmniSharp, execute the ps aux | grep OmniSharp.exe
command. If the process is running, the following is an example output:
/tmp/theia-unpacked/redhat-developer.che-omnisharp-plugin.0.0.1.zcpaqpczwb.omnisharp_theia_plugin.theia/server/bin/mono /tmp/theia-unpacked/redhat-developer.che-omnisharp-plugin.0.0.1.zcpaqpczwb.omnisharp_theia_plugin.theia/server/omnisharp/OmniSharp.exe
If the output is different, the language server has not started inside the container. Check the logs described in Checking important logs.
Viewing logs for Dotnet with NetcoredebugOutput plug-in
NetcoredebugOutput plug-in
The NetcoredebugOutput plug-in provides the netcoredbg
tool.
This tool implements the VS Code Debug Adapter protocol and allows users to debug .NET applications under the .NET Core runtime.
The container where the NetcoredebugOutput plug-in is running contains Dotnet SDK v.2.2.105.
Verifying the state of the NetcoredebugOutput plug-in
To test the plug-in initialization:
-
Check if there is a netcoredbg debug configuration in the
launch.json
file. The following is an example debug configuration:{ "type": "netcoredbg", "request": "launch", "program": "$\{workspaceFolder}/bin/Debug/<target-framework>/<project-name.dll>", "args": [], "name": ".NET Core Launch (console)", "stopAtEntry": false, "console": "internalConsole" }
-
To test if it exists, test the autocompletion feature within the braces of the
configuration
section of thelaunch.json
file. If you can findnetcoredbg
, the Che-Theia plug-in is correctly initialized. If not, see Checking important logs.
Viewing logs for Camel
Verifying the state of the Camel language server
The user can inspect the log output of the sidecar container using the Camel language tools that are stored in the vscode-apache-camel<xxx>
Camel container.
To verify the state of the language server:
-
Open a terminal inside the
vscode-apache-camel<xxx>
container. -
Run the
ps aux | grep java
command. The following is an example language server process:java -jar /tmp/vscode-unpacked/camel-tooling.vscode-apache-camel.latest.euqhbmepxd.camel-tooling.vscode-apache-camel-0.0.14.vsix/extension/jars/language-server.jar
-
If you cannot find it, see Checking important logs.
Viewing Camel logs in the Output panel
The Camel language server is a SpringBoot application that writes its log to the $\{java.io.tmpdir}/log-camel-lsp.out
file. Typically, $\{java.io.tmpdir}
points to the /tmp
directory, so the filename is /tmp/log-camel-lsp.out
.
The Camel language server logs are printed in the Output channel named Language Support for Apache Camel.
The output channel is created only at the first created log entry on the client side. It may be absent when everything is going well. |
Viewing Che-Theia IDE logs
This section describes how to view Che-Theia IDE logs.
Viewing Che-Theia editor logs using the OpenShift CLI
Observing Che-Theia editor logs helps to get a better understanding and insight over the plug-ins loaded by the editor. This section describes how to access the Che-Theia editor logs using the OpenShift CLI (command-line interface).
-
Che is deployed in an OpenShift cluster.
-
A workspace is created.
-
User is located in a Che installation namespace.
-
Obtain the list of the available Pods:
$ oc get pods
Example$ oc get pods NAME READY STATUS RESTARTS AGE che-9-xz6g8 1/1 Running 1 15h workspace0zqb2ew3py4srthh.go-cli-549cdcf69-9n4w2 4/4 Running 0 1h
-
Obtain the list of the available containers in the particular Pod:
$ oc get pods <name-of-pod> --output jsonpath='\{.spec.containers[*].name}'
Example:$ oc get pods workspace0zqb2ew3py4srthh.go-cli-549cdcf69-9n4w2 -o jsonpath='\{.spec.containers[*].name}' > go-cli che-machine-exechr7 theia-idexzb vscode-gox3r
-
Get logs from the
theia/ide
container:$ oc logs --follow <name-of-pod> --container <name-of-container>
Example:$ oc logs --follow workspace0zqb2ew3py4srthh.go-cli-549cdcf69-9n4w2 -container theia-idexzb >root INFO unzipping the plug-in 'task_plugin.theia' to directory: /tmp/theia-unpacked/task_plugin.theia root INFO unzipping the plug-in 'theia_yeoman_plugin.theia' to directory: /tmp/theia-unpacked/theia_yeoman_plugin.theia root WARN A handler with prefix term is already registered. root INFO [nsfw-watcher: 75] Started watching: /home/theia/.theia root WARN e.onStart is slow, took: 367.4600000013015 ms root INFO [nsfw-watcher: 75] Started watching: /projects root INFO [nsfw-watcher: 75] Started watching: /projects/.theia/tasks.json root INFO [4f9590c5-e1c5-40d1-b9f8-ec31ec3bdac5] Sync of 9 plugins took: 62.26000000242493 ms root INFO [nsfw-watcher: 75] Started watching: /projects root INFO [hosted-plugin: 88] PLUGIN_HOST(88) starting instance