KluthR
-
Posts
702 -
Joined
-
Last visited
-
Days Won
5
Content Type
Profiles
Forums
Downloads
Store
Gallery
Bug Reports
Documentation
Landing
Report Comments posted by KluthR
-
-
Indeed. Ignored that. I still remember that @CiscoCoreX mentioned clearly a normal operation after downgrading.
To clarify all currently affected users should make tests (which is not doable on prod).
I still making some tests with @CiscoCoreX in background. Maybe we just observe the behavior for now. But it seemed weird that users explicitly reported this after .4. As I understood, the exec‘s were executed several times below .4 as well, right? 🤔
-
1
-
-
14 minutes ago, ljm42 said:
Not sure why they are so slow (maybe they are slow flash drives?)
But its only happening since .4
14 minutes ago, ljm42 said:as long as the webgui limits writes to the flash drive it sounds like the slowness doesn't cause noticeable issues.
Indeed! I agree but now we know there is something. And it doenst feel 100% right because there is nothing obvious which could caused it.
The initial issue could be closed, yes, but myself is interested whats the root cause. But those IO things are out of my knowledge if dmesg is not giving any obvious informations.
-
15 minutes ago, ljm42 said:
But the kernel version is not what fixed the issue when downgrading. It is that the older release didn't have this webgui code:
The main reason is slow flash drive writes on .4+ which get back to normal at .3. Not any webgui issue at all.
@CiscoCoreX correct me if Iam wrong but the „echo 1 > /boot/test“ command delays on .4 onwards and is immediately done for .3?
correct me if Iam wrong, but the root cause is not fixed at all. The webgui introduced a workaround now which is perfectly fine.
-
-
1 hour ago, bonienl said:
Though it is still a mystery to me why some people have slow write access to their flash device
Downgrading fixed those issues. Were there big changes between .3 and .4 in the linux base system? I did not checked any diags from affecting users: is dmesg/kernel log saying something?
-
7 hours ago, bonienl said:
I made an update for two files which check for changes in the docker configuration and update as needed.
Did not took a look but what is the fix actually? Calling exec with sed only of really needed?
If yes: This fixes the always-calling-sed-issue but what is the underlying write-to-boot-is-slow issue then?
-
I let @CiscoCoreX do several „echo 1 > /boot/test.xml“ which delayed up to 6 seconds. (Btw, could you test „echo 1 > /mnt/user/someshare/test.txt“ with started array and real share name?)
downgrading fixes all delays.
The issue seems to be Linux related. At least nothing to do with webgui.
anyway, Iam out now. The slowlog brought a new finding which was my only idea 😂
Maybe LimeTech can share some thoughts on this.
-
1
-
-
I just checked - the rc.docker command has this sed in it as well. Those write back to USB Boot drive. This is what me brings me back to bonie's suggestion to check the Boot-Drive. The sed would be extremely slow, when writes to the USB drive would be slow (a failing device maybe?). But ANY write would be slow then.
Maybe a performance check with CrystalDiskMark would expose issues writing to the USB key.
Iam very curious if this could be the root cause for all affected users.
-
Yes, seems unnecessary, but why is a sed so slow?
-
But is the mentioned command taking so long anyway? Unraid calls this command regardless of docker/vms enabled/disabled. If there is any "issue" in the script, it could be triggered anyway. Please try it and report back.
EDIT: If the docker status command is not delaying, please share the PHP-Slowlog for your system.
-
17 hours ago, bonienl said:
Ps. The file "php.slow.log" shows the dashboard page loading takes a long time (duh) without further details.
And why dont we dig deeper there? There are further details.
I checked the eval'd code. The affected page is DashStats and line 53 is the docker status exec.
I asked him to execute the rc.docker status command and this command takes ~20 secs to complete, so here we have our issue at least for him.
The question is: Is this the same cause for all others? And if yes, what is taking so long time inside the rc.d script for some users.
For others having the issue, I would ask them to execute the command "/etc/rc.d/rc.docker status" in a terminal and observe, how many seconds it need to generate output.
That are my findings. Correct me if anything looks wrong.
-
1
-
-
Please test the following to see what is being executed while the delay happens:
- Open /etc/php-fpm.d/www.conf
- Uncomment ";slowlog ="
- Adapt the same line to "slowlog = /var/log/php.slow.log"
- Uncomment ";request_slowlog_timeout = 0"
- Change the same line to "request_slowlog_timeout = 10"
Open a terminal (SSH) and type in "/etc/rc.d/rc.php-fpm restart"
Try to reproduce the delay. After this, Upload the file at /var/log/php.slow.log here. Then please add a semicolon (;) to BOTH changed lines again and restart PHP-FPM again.
This will show us a trace on the portion of code, which lasts longer than 10 seconds.
Offtopic: The Pool Config could get updated to latest package templates - inside of the current one there still PHP5 metioned. The nginx socket paths could get updated too..
-
1
-
Never had issues with the "original" br0 macvlan, but looking at the technical details: The new macvtap method seems nice and could be the new default, if I understand things correctly. Even if the kernel bug gets addressed, the macvtap on ethX seems a better default. Correct me if misunderstood something.
-
2
-
-
And /root/.bash_profile ?
whats happening when you run
su -s /bin/sh root? Is it hanging as well?
-
Just a shot in the dark: something inside /root/.profile or /root/.bashrc which could cause that?
if the issue happens, what is the line for root inside /etc/passwd?
-
Cant agree. My RC6 is showing the pull info just as usual. With growing percents during downloading layers etc.
[6.12.4/5/6] Major GUI delays after upgrade (specially dashboard, docker and apps tab)
in Stable Releases
Posted
Yes. You are right. Mixed that up.