Jump to content

slushieken

Members
  • Posts

    20
  • Joined

  • Last visited

Posts posted by slushieken

  1. Ok this is strange but I think if you are just patient, the GUI can connect again.

     

    I couldn't get my browser to connect to the GUI port 8080 either after a very recent reboot (few days ago). My guess is it was related to an upgrade I just completed to 6.12.8, for which I rebooted. It seemed to be working fine until that upgrade and reboot. I had stopped the container until I could troubleshoot better.


    I rebooted this AM a couple of times, noticed I still could not connect, and I started gathering the docker logs to post here. Then I thought I would run a TCP packet capture to assess whether it was networking or the application itself. After about 10 mins time (while I was writing this post in fact) I notice the docker log suddenly updated with a bunch of new lines, and I could then connect to the GUI port normally!

     

    I'll watch to see if I can help further, but I next need to know how to gather the supervisord.log for you.

    I use and am still using 'Bridge' network mode only.

  2. On 10/12/2023 at 11:38 PM, Kayn said:

    In the log I get: "[error] grafana crashed!" Is there a way to fix this ?

    I am doing a fresh, new install of latest, and getting this too. I have tried at least 3 different repo's and 3 different revisions- no luck.

     

    The good news is this repo is the one that comes closest to working - only grafana is failing.

     

    The logs in the container are absolutely empty for grafana.

    At console I execute "grafana-server" it says "Grafana-server Init Failed: Could not find config defaults, make sure homepath command line parameter is set or working directory is homepath"

     

    Can someone kind soul out there take a look at this? There are too many building blocks required to get this stack working, and I am not familiar enough with any of them to even start troubleshooting through those.

     

    🤕

     

    Thank you.

  3. I drew this basic Silverstone CS351 png to populate my dashboard, since there is not an existing image for that. I used a picture of the server front as a guide, and traced the outline over that. 

     

    I see others in this thread include 3 different copies for their png's. On my Unraid server (the way I use it), I didn't find a place to use those. So I searched this thread for a set of requirements, eg what is needed for a full set of images, and where those would be uploaded, but I couldn't find an explanation.

    Someone who understands better what is needed and why/where it goes - it would have been helpful to have that so I could create a full set.

    Anyway, here is what I have so far.

    cs351.png

    • Like 1
  4. I just wanted to say this script is just... amazing. I have been working on cleaning up nearly 20TB of movies and tv shows for several years now split incorrectly over time due to this or that, settings errors on splits, etc.

     

    I have been having success over that time with many different methods and a hit and miss effort, but yours wrapped it all up in one fell swoop.

     

    Thank you.

  5. Steini, I just discovered this plugin... really want to use it. But, I am at at current release:

     

    kernel: Linux version 4.4.23-unRAID (root@develop64) (gcc version 5.3.0 (GCC) ) #1 SMP PREEMPT Sat Oct 1 13:41:00 PDT 2016

     

    I am sure it is a pain to do this each time, but can you compile again vs. current 6.2.1?

     

     

  6. I have been receiving this error regularly for some time.

     

    unregister_netdevice: waiting for lo to become free. Usage count = 1

     

    Much of the time, it is harmless and nothing happens.

     

    Sometimes though, everything grinds to very nearly a full stop re: networking.

     

    This is full OS affecting and I cannot connect via the GUI at all, and even when connected via SSH/Telnet command completion becomes hard as the connection goes in and out. This situation remains so, until a full reboot can be executed. Can't test restarting docker only, as connectivity becomes so problematic at that point issuing commands becomes difficult.

     

    It seems, via research, this is a cross platform kernel related issue, and shows up most commonly when using docker containers with high network activity (for example, torrents). It seems it is also intermittent, and therefore hard to reproduce except in a production environment with lots of connections.

     

    Devs indicate it seems to be related to hairpin mode networking, and if this can be disabled it stops. Hairpin mode is used by default on containers.

     

    Suggested workarounds found so far are:

     

    Disable IPV6 in the containers. hard to do as even if docker is configured to not use IPV6, it seems it still uses it anyway. Additionally, even when disabled in the kernel via boot parameters, many say it did not fix the issue.

     

    Set docker networking to promiscuous mode. This disables hairpin mode. Anyone know how to do this on a container? I don't know myself. This worked for users of kubernetes and some others.

     

    Final suggestions I would offer are to:

     

    Not use docker containers for torrents. Only until fixed anyway. I am probably going this route unless I can get promiscuous mode going, and it works.

     

     

×
×
  • Create New...