TrueNAS Scale GUI Sluggish and Unresponsive

System updated 23 days ago to “OS Version:25.04.2.4”, and now the GUI is sluggish and unresponsive.
It takes two to four attempts to login, each time throwing you back to the login page.
Username and password are correct.
Everything else is working just fine.
Docker containers all running smoothly, and ssh session to the server has no issues.
SMB sessions also normal as expected.

I know rebooting the system will resolve the issue, but I would rather try and figure out why this is happening.

System running on a Dell R430 with dual CPUs.
( **Cores:**12 cores **Threads:**24 threads)
(120GB memory and running around 10% Average Usage)

Have you tried running top in the shell to see the usage of processes?

That is the first thing I did, and the system is performing, like I mention around 10% average, but I do not know which process is running the GUI.

I hate to ask, but if this was a major update, have you cleared the browser cache for the TrueNAS IP/DNS name?

It was an update from 25.04.2.3.
I have tried different browsers with the same issue, and I always clear down all caches etc when I close down the browser.

If you’re able to get logged in, a debug would be appreciated.

sudo service middlewared restart will bounce the middleware from SSH without taking down sharing services.

1 Like

Before I restart the middlewared process I tried to find it using top, but to no avail.
I then run “ps -ef | grep middlewared” and found the following:

root 2951 1 58 Sep13 ? 14-01:11:01 middlewared
root 3193515 2951 0 13:43 ? 00:00:05 middlewared (worker)
root 3865075 2951 0 16:57 ? 00:00:00 middlewared (worker)
root 3868550 2951 0 16:57 ? 00:00:00 middlewared (worker)
root 3872215 2951 0 16:58 ? 00:00:00 middlewared (worker)
root 3875785 2951 1 16:59 ? 00:00:00 middlewared (worker)

I then restarted the process, and the following was displayed with the “ps” command:

root 3894758 1 72 17:05 ? 00:00:33 middlewared
root 3894939 3894758 10 17:05 ? 00:00:01 middlewared (worker)
root 3894952 3894758 52 17:05 ? 00:00:07 middlewared (zettarepl)
root 3895019 3894758 9 17:05 ? 00:00:01 middlewared (worker)

Don’t know what the meaning of “zettarepl”.

The GUI is now back to normal, and load average is now 3%.

At least restarting the process restores the GUI without having to reboot the server, but I am still none the wiser why it occurred.

Thanks for your assistance, much appreciated.

zettarepl is the tool performing replication tasks.

2 Likes

I exported the debug.log, and had a looksee at the “middlewared.log”.

Just to point out that my system has no internet access.

Below seems to be something of interest, but I have no clue what it’s relating to.

//
[2025/10/06 21:49:54] (DEBUG) IdmapDomainService.id_to_name():1185 - timeout encountered while trying to convert user id 0 to name. This may indicate significant networking issue.
[2025/10/06 21:49:59] (DEBUG) IdmapDomainService.id_to_name():1185 - timeout encountered while trying to convert group id 0 to name. This may indicate significant networking issue.
[2025/10/06 21:50:20] (DEBUG) IdmapDomainService.id_to_name():1185 - timeout encountered while trying to convert user id 0 to name. This may indicate significant networking issue.
[2025/10/06 21:50:25] (DEBUG) IdmapDomainService.id_to_name():1185 - timeout encountered while trying to convert group id 0 to name. This may indicate significant networking issue.
[2025/10/06 21:50:56] (WARNING) middlewared._loop_monitor_thread():1322 - Task seems blocked:\n File “/usr/lib/python3/dist-packages/middlewared/main.py”, line 720, in _call\n return await methodobj(*prepared_call.args)\n File “/usr/lib/python3/dist-packages/middlewared/plugins/account.py”, line 296, in user_extend\n user[‘sshpubkey’] = await self.middleware.run_in_thread(self.read_authorized_keys, user[‘home’])\n File “/usr/lib/python3/dist-packages/middlewared/main.py”, line 627, in run_in_thread\n return await self.run_in_executor(io_thread_pool_executor, method, *args, **kwargs)\n File “/usr/lib/python3/dist-packages/middlewared/main.py”, line 624, in run_in_executor\n return await loop.run_in_executor(pool, functools.partial(method, *args, **kwargs))\n File “/usr/lib/python3.11/asyncio/base_events.py”, line 830, in run_in_executor\n executor.submit(func, *args), loop=self)\n File “/usr/lib/python3/dist-packages/middlewared/utils/threading.py”, line 41, in submit\n start_daemon_thread(name=f"ExtraIoThread{next(counter)}", target=worker, args=(fut, fn, args, kwargs))\n File “/usr/lib/python3/dist-packages/middlewared/utils/threading.py”, line 24, in start_daemon_thread\n t.start()\n File “/usr/lib/python3.11/threading.py”, line 969, in start\n self._started.wait()\n File “/usr/lib/python3.11/threading.py”, line 629, in wait\n signaled = self._cond.wait(timeout)\n File “/usr/lib/python3.11/threading.py”, line 327, in wait\n waiter.acquire()\n
[2025/10/06 21:51:06] (DEBUG) IdmapDomainService.id_to_name():1185 - timeout encountered while trying to convert user id 0 to name. This may indicate significant networking issue.
[2025/10/06 21:51:11] (DEBUG) IdmapDomainService.id_to_name():1185 - timeout encountered while trying to convert group id 0 to name. This may indicate significant networking issue.
//

Are you using any outside directory services (LDAP/AD) on this system?

Yes, there are two OpenLDAP docker containers running, but not used for TrueNAS authentication.

They are used for the Docker architecture, but I have listed them in the Credentials LDAP configuration to ensure they are correctly set.

I have just noticed that they are enabled in the config which was not the intention.

I have now disabled them.