6 hours ago, JorgeB said:

Please retest with 7.1.3

same for me, thank you!

11 hours ago, Naticus said:

Change ipvlan to macvlan. Disable allowing host access to custom networks. Disable custom interface br0.

maybe give it a try withoud "disable host access".

 

for me just this worked:

-docker stop

-only choose macvlan (letting host access active)

-docker start

-wait for alle containers are started

-docker stop

-switch to ipvlan

-docker start

 

still present in 7.1.2 after update from 7.1.1

Very annoying problem. Hope the hotfix patch doesn't need very long to release, especially because it is present since RC4 and makes a unraid-server unusable if host-access is In use.

I just found the reason for failing DNS resolves after researching of hours.

@erf89 @asychev

 

could you please post your docker run command?

 

also please post the output from the following terminal command:

docker network list

 

1 hour ago, JorgeB said:

please post new diags to see if there's something else in common.

 

unraid-1-diagnostics-20241006-2012.zip

Changed Status to Solved

so, in every syslog from the past, i found this line: 

Sep 11 22:26:02 Unraid-1 crond[1944]: exit status 255 from user root php /usr/local/emhttp/plugins/community.applications/scripts/notices.php > /dev/null 2>&1

after that, the GUI stopped working.

 

i unistalled and reinstalled the plugin. now the unraid gui workes fine for the last 3 weeks.

 

i think there was a problem with the "User Notes" Plugin:

 

is there maybe a temporary fix? my whole syslog is spammed by this.

here i got the same on 7-0-0-beta.2 with the diagnostic: 

 

Changed Status to Closed

@JorgeB thanks for the explanation

should i close the report status?

1 hour ago, JorgeB said:

This is a very old issue:

okay, that was the reason i reported it with the 7.0.0beta2

but it looks like it is unfixable?

On 7/20/2024 at 8:10 PM, JorgeB said:

in normal boot it usually happens in 1 to 3 days.

Maybe something to do with RAM?

 

I had just 32GB RAM until i upgrade two day before. On 32GB the calltrace come instantly.

 

Here i marked the Calltrace at 15:28PM. After a reboot this morning there wasn't any calltrace yet.

so, today i did a RAM upgrade. From 32GB to 64GB.

 

With 32GB RAM the calltrace came straight after all my docker containers started up.

Now with 64GB the calltrace came with a delay of a few hours.

 

I don't know if this is of interest.

unraid-1-diagnostics-20240911-1554.zip

@JorgeB

okay thanks, i will try this.

3 minutes ago, JorgeB said:

or try limiting its RAM usage.

 

this is the limition, isn't it?

i didn't add this command, this is part of the template by default.

30 minutes ago, JorgeB said:

I believe I tested without docker and still got the call trace, but not 100% sure, I'll retest.

maybe something trigger by docker, or a  specific container faster, than without any container running?
but okay... hard to find.

for me, it feels like it has something todo with docker?

when i start my server, the call trace doesn't appear.

after i start docker, the call traces comes, immediately when all containers has started.

ipv6 is more and more common in germany. fd00:: addresses are static addresses for LAN communication. while the prefix on the ipv6-addresses you get from your ISP will change from time to time, the ULA address will stay static.

5 minutes ago, pkoci said:

I've got the same problem.

☝️please post diagnostics

1 minute ago, JorgeB said:

any idea where the second one is coming from?

2003:... is the public one from ISP

fd00::... is the internal one ULA (https://en.wikipedia.org/wiki/Unique_local_address)

there must be also a third one... (LLU)

4 minutes ago, JorgeB said:

Probably not, but also post output of

 

1 hour ago, alturismo said:

cat /etc/ntp.conf | grep interface

To see  if there's something else there

 

root@Unraid-1:~# cat /etc/ntp.conf | grep interface
interface ignore wildcard
interface listen 192.168.0.50 # eth0
interface listen fd00::aaa1:59ff:fe2b:ccfd # eth0
interface listen 2003:c0:cf2c:cd00:aaa1:59ff:fe2b:ccfd # eth0
root@Unraid-1:~# 

 

no, there is only keepalived inside a LXC container on my server

 

same for me

unraid-1-diagnostics-20240719-0743.zip

On 7/2/2024 at 9:56 AM, itimpi said:

Have you gone into the scheduler settings and made a change to the parity check ones and clicked "Apply"?

 

On 7/2/2024 at 9:59 AM, JorgeB said:

you will need to do a dummy change to create the corrected cron entry.

oh, didn't know that, so i am sorry.

i will do the dummy change and test it again.

thank you!