Tail Following UI Stops Updating (when using Highlighting Actions, such as Plugin or Set Bookmark)

[EnigmaSolved]

Tail Following stops working after a while. I'm using this 1.21 Snapshot Debug release. What kind of logs should I check/collect to help diagnose this? I realize from a prior conversation that this issue could be particular to me, but would still love to figure out what is going on. Tail Following works initially, but then at some point it just stalls out and won't work again until restarting the app.

Something that is probably related is that if I save my session and try to then load it I get the following error:

Cannot load file
No file system plugin found for
\__wsl.localhost_Ubuntu_REST_OF_FILE_NAME.lxp

Logs are located in a folder on a Linux WSL2 (Windows Subsystem for Linux) installation on Windows 11 Pro:
\\wsl.localhost\Ubuntu\....

The logs continue to be accessible to me if I manually check them, so it is not that they are going "offline" or something (as far as I can tell). But them being located on WSL2 very well may be part of my issue for some reason.

[AndisGrossteins]

Something that is probably related is that if I save my session and try to then load it I get the following error:

Cannot load file
No file system plugin found for
\__wsl.localhost_Ubuntu_REST_OF_FILE_NAME.lxp

That filename extension indicates it's the session persistence file. You previously mentioned that you're using LogExpert in portable mode and persistence files are saved next to the log files which is undesirable.

In this case the UNC path is causing issues because LogExpert replaces backslashes (\) with underscores (_) in log file path to create the filename for persistence file. As a result, the path to persistence file \__wsl.localhost_Ubuntu_REST_OF_FILE_NAME.lxp lacks the two backslashes which on Windows indicates a UNC path, which is handled via Plan9 (9P) protocol in WSL2.

Logs are located in a folder on a Linux WSL2 (Windows Subsystem for Linux) installation on Windows 11 Pro: \\wsl.localhost\Ubuntu\....

I've never tried to load log files from WSL into LogExpert but I'm using WSL2 almost daily so I can test what's exactly going on by debugging LogExpert in Visual Studio.

[AndisGrossteins]

@EnigmaSolved What's your current "Persistence file location" setting and do you start LogExpert by double-clicking a file in Windows Explorer?

[AndisGrossteins]

While debugging LogExpert in portable mode and loading /var/log/syslog from WSL2 and so far follow tail is working as expected for over an hour.

To see what's going on on the WSL side, please enable debug console output to a file by adding following options to %UserProfile%\.wslconfig:

[wsl2]
debugConsole=true
debugConsoleLogFile=C:\\temp\\WSL_Debug_Console.log

And then force WSL service shutdown using wsl.exe --shutdown for the configuration changes to take effect.

I can reproduce the second issue with saving of persistence files when using "Application startup directory";
LogExpert tries to create file in the root directory of C:

LogExpert.Core.Classes.Persister.Persister|Error saving persistence data to \__wsl.localhost_Ubuntu_Legacy_var_log_syslog.lxpAccess to the path 'C:\__wsl.localhost_Ubuntu_Legacy_var_log_syslog.lxp' is denied. System.UnauthorizedAccessException System.UnauthorizedAccessException: Access to the path 'C:\__wsl.localhost_Ubuntu_Legacy_var_log_syslog.lxp' is denied.
   at Microsoft.Win32.SafeHandles.SafeFileHandle.CreateFile(String fullPath, FileMode mode, FileAccess access, FileShare share, FileOptions options)
   at Microsoft.Win32.SafeHandles.SafeFileHandle.Open(String fullPath, FileMode mode, FileAccess access, FileShare share, FileOptions options, Int64 preallocationSize, Nullable`1 unixCreateMode)
   at System.IO.File.OpenHandle(String path, FileMode mode, FileAccess access, FileShare share, FileOptions options, Int64 preallocationSize)
   at System.IO.File.WriteToFile(String path, FileMode mode, ReadOnlySpan`1 contents, Encoding encoding)
   at System.IO.File.WriteAllText(String path, String contents, Encoding encoding)
   at LogExpert.Core.Classes.Persister.Persister.Save(String fileName, PersistenceData persistenceData) in C:\Development\LogExpert\src\LogExpert.Core\Classes\Persister\Persister.cs:line 237

The reason behind this behaviour is that the dir variable is left empty and then a path separator is added, which evaluates to the root of current drive (C:\) here:

LogExpert/src/LogExpert.Core/Classes/Persister/Persister.cs

Lines 181 to 187 in a16b899

	case SessionSaveLocation.ApplicationStartupDir:
	{
	//TODO Add Application.StartupPath as Variable
	dir = string.Empty;// Application.StartupPath + Path.DirectorySeparatorChar + "sessionfiles";
	file = dir + Path.DirectorySeparatorChar + BuildSessionFileNameFromPath(logFileName);
	break;
	}

The TODO note states the obvious.

[Hirogen]

thats an oversight, this should have been added already, the reason I forgot about it, is that the persister is now its own project and has no knowledge of the "Application" Context, so this variable has not been set.

[EnigmaSolved]

@EnigmaSolved What's your current "Persistence file location" setting and do you start LogExpert by double-clicking a file in Windows Explorer?

My persistence files are saved in the "Application startup directory". You were recalling that in a prior LogExpert version even though I was in Portable Mode it was trying to save them to the log directory which is not writable (and so it was failing).

And yes, I double-click LogExpert.exe in Windows Explorer.

I'm not able to this moment, but I will try the updated debug release as soon as I can, and then also do the WSL debug logging you shared. Appreciate you both and all that you've shared, and apologies for delayed reply (time zone differences!).

[EnigmaSolved]

I just tried a new debug version which I thought incorporated #507, but I'm still seeing the same error when trying to load the session:

Cannot load file
No file system plugin found for
\__wsl.localhost_Ubuntu_REST_OF_FILE_NAME.lxp

I wonder if I'm missing something, or if maybe we still have something unresolved?

[AndisGrossteins]

I'm still seeing the same error when trying to load the session:

Cannot load file
No file system plugin found for
\__wsl.localhost_Ubuntu_REST_OF_FILE_NAME.lxp

That's strange. How are you opening the session file and where is it stored?

[EnigmaSolved]

It is stored in the application directory, and I'm trying to load it via the File -> Load session menu.

[AndisGrossteins]

It is stored in the application directory, and I'm trying to load it via the File -> Load session menu.

Could you open the session file (*.lxj) in a text editor and post the FileNames part here enclosed in a code block?

Mine for example:

  "FileNames": [
    "\\\\wsl.localhost\\Ubuntu_Legacy\\var\\log\\mail.log.lxp",
    "\\\\wsl.localhost\\Ubuntu_Legacy\\var\\log\\syslog.lxp",
    "C:\\var\\log\\WSL_Debug_Console.log.lxp"
  ]

I'm getting a broken UI with multiple detached windows when I load a session but that's a different issue. No error messages, however.

As for the primary issue of "tail following" not working after a while, I can't reproduce it.

I left LogExpert monitoring /var/log/syslog for over 12 hours and even logged out of WSL session to check if it's not caused by the idle timeout. It's still refreshing and showing new entries.

As NLog log entries show it's being monitored and updated:

2025-12-03 18:09:01.5698|INFO|LogExpert.Core.Classes.Log.LogfileReader|file size changed. new size=43612, file: \\wsl.localhost\Ubuntu_Legacy\var\log\syslog
2025-12-03 18:09:03.7290|INFO|LogExpert.Core.Classes.Log.LogfileReader|file size changed. new size=43683, file: \\wsl.localhost\Ubuntu_Legacy\var\log\syslog
2025-12-03 18:09:04.0289|INFO|LogExpert.Core.Classes.Log.LogfileReader|file size changed. new size=43838, file: \\wsl.localhost\Ubuntu_Legacy\var\log\syslog
2025-12-03 18:17:01.4323|INFO|LogExpert.Core.Classes.Log.LogfileReader|file size changed. new size=43934, file: \\wsl.localhost\Ubuntu_Legacy\var\log\syslog

[EnigmaSolved]

  "FileNames": [
    "\\__wsl.localhost_Ubuntu_volume1_docker_crashplan_log_history.log.0.lxp",
    "\\__wsl.localhost_Ubuntu_volume1_docker_crashplan_log_backup_files.log.0.lxp",
    "\\__wsl.localhost_Ubuntu_volume1_docker_crashplan_log_service.log.0.lxp"
  ]

I think I figured out part of it: I created this session on an older version. When I just now created a new session it loads without errors.

  "FileNames": [
    "C:\\Users\\Sean\\Downloads\\LogExpert\\sessionFiles\\__wsl.localhost_Ubuntu_volume1_docker_crashplan_log_service.log.0.lxp"
  ]

However, LogExpert is still not restoring a session automatically on open (even though that setting is turned on).

Where do I look for NLog log entries and/or how do I turn them on? I still have the NLog config in this folder from the prior conversation, but I am not seeing where the logs are.

[AndisGrossteins]

However, LogExpert is still not restoring a session automatically on open (even though that setting is turned on).

I assume you meant the "Re-open last used files" option. That feature stores an array of opened files in the settings.json file as LastOpenFilesList and file-specific settings are saved by the persistence feature.
If the previously opened files are not accessible during startup, LogExpert should show an error message or at least log an error to the NLog log file (if that's enabled).

Where do I look for NLog log entries and/or how do I turn them on? I still have the NLog config in this folder from the prior conversation, but I am not seeing where the logs are.

When using the NLog.config form repository the log entries are written to C:\Temp\LogExpert\logs\logexpert.log.

Here's an alternative NLog.config I'm using:

<?xml version="1.0" encoding="utf-8" ?>
<nlog xmlns="http://www.nlog-project.org/schemas/NLog.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xsi:schemaLocation="http://www.nlog-project.org/schemas/NLog.xsd NLog.xsd"
      autoReload="true"
      throwExceptions="false"
      throwConfigExceptions="false"
      internalLogLevel="Warn"
      internalLogFile="c:\temp\nlog-internal.log">

	<targets>
		<target name="logfile" xsi:type="File"
			fileName="${basedir}\logs\logexpert.log"
			layout="${longdate}|${level:uppercase=true}|${logger}|${message}|${exception:format=Type,ToString:innerFormat=Type,ToString:maxInnerExceptionLevel=10:innerExceptionSeparator=-----------------------}"
			header="${longdate} Started ${processname:fullName=true} PID ${processid} ver ${assembly-version} at ${processinfo:property=StartTime}"
			encoding="utf-8"
			encoding="utf-8" archiveEvery="Day"
			archiveFileName="${basedir}\logs\Archive\logexpert{#}.log"
			archiveDateFormat="yyyy-MM-dd"
			maxArchiveFiles="10"
			createDirs="true"
			writeHeaderWhenInitialFileNotEmpty="true"
			archiveOldFileOnStartup="false" />
	</targets>

	<rules>
		<logger name="LogExpert.PluginRegistry.*" finalMinLevel="Info" />
		<logger name="*" minlevel="Info" writeTo="logfile" />
	</rules>
</nlog>

With this configuration log will be written to logs\logexpert.log in the application base directory.

The NLog project has extensive documentation of the configuration files on GitHub: https://github.com/nlog/nlog/wiki/Configuration-file and on project site: https://nlog-project.org/config/

[EnigmaSolved]

That is super-helpful, thank you! I somehow managed to download a webpage as my NLog.config -- I must have dragged/dropped the link you'd previously shared, instead of properly downloading it 😆, so that was total user-error on my part. Apologies! NLog is now working properly (now that I have a true config).

So I'll use that to monitor the Tail Following issue, and report back.

And yes, I mean the Re-open last used files feature (thanks for interpreting correctly!). So in my settings I see this (which would explain why nothing is being opened 😆):

  "LastDirectory": "\\\\wsl.localhost\\Ubuntu\\volume1\\docker\\crashplan\\log",
  "LastOpenFilesList": [],

As far as I can tell there are no relevant errors in NLog, and LastOpenFilesList is not being updated when I add files (I currently have one of the wsl crashplan logs and the NLog loaded).

[Hirogen]

the lastOpenFilesList is always cleared before saving and all currently open files are saved.
So if you close all files before closing logexpert, the list will be empty