• [6.7.0-rc4] Web Console Stops Working


    Taddeusz
    • Retest Annoyance

    I've had this happen once before. I will be using the console and it will all of a sudden freeze. I close the console window and try to re-open it but all I get is an empty white window. The console never re-opens. The only thing that seems to fix it is a reboot. I'm using the latest version of Chrome on macOS Mojave.

    unraid-diagnostics-20190221-1727.zip




    User Feedback

    Recommended Comments



    g morning, just as quick test today morning i see it happened again, as note ...

    command was ps x

     

    the last entry from system log

     

    Mar 1 07:01:42 AlsServer login[12318]: ROOT LOGIN on '/dev/pts/2'

     

    is there no option to restart the service ? exept server reboot ?

    image.thumb.png.1f4f738459e2d8d420ba7cb62de76974.png

    Link to comment

    when i killall ttyd instances i then get a bad gateway instead about:blank when trying terminal again

     

    i assume ttyd need a restart, may a hint wich options to use ?

     

    image.thumb.png.034e19a7c1b7a214a956906cc64d371f.png

     

    image.thumb.png.1ba6bb3ee860cd5ff4d00278919c2dbb.png

    Link to comment

    Finally had this happen on a test server.  I could not find any reason why the ttyd daemon quit responding to connection requests.  Probably this is a bug in ttyd or libwebsockets it depends on.  We have updated the latter in the next release and let's see if this happens again.

     

    To recover from this you can use telnet/ssh/console and type this command:

    /etc/rc.d/rc.nginx restart

     

    Link to comment
    8 hours ago, limetech said:

    Finally had this happen on a test server.  I could not find any reason why the ttyd daemon quit responding to connection requests.  Probably this is a bug in ttyd or libwebsockets it depends on.  We have updated the latter in the next release and let's see if this happens again.

     

    To recover from this you can use telnet/ssh/console and type this command:

    
    /etc/rc.d/rc.nginx restart

     

    thanks for the Tipp

    Link to comment
    21 hours ago, limetech said:

    Finally had this happen on a test server.  I could not find any reason why the ttyd daemon quit responding to connection requests.  Probably this is a bug in ttyd or libwebsockets it depends on.  We have updated the latter in the next release and let's see if this happens again.

     

    To recover from this you can use telnet/ssh/console and type this command:

    
    /etc/rc.d/rc.nginx restart

     

     

    Hey @limetech I hit this today in 6.7.0-rc5.  But when I ran:

    /etc/rc.d/rc.nginx restart

    nginx shutdown and did not start backup:

    Checking configuration for correct syntax and
    then trying to open files referenced in configuration...
    nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
    nginx: configuration file /etc/nginx/nginx.conf test is successful
    Shutdown Nginx gracefully...
    Nginx is already running
    

    It looks like it tried to start back up before it finished shutting down, so it exited.

     

    I had to manually start it to get it running again:

    /etc/rc.d/rc.nginx start

     

    I was looking at rc.nginx, what do you think of creating a wait_nginx_status function:

    wait_nginx_status() {
      while nginx_status; do 
        echo "Waiting..."
        sleep 1
      done
    }

    And then replacing all of the "sleep 3"s with that:

    nginx_stop() {
      if nginx_running ; then
        echo "Shutdown Nginx gracefully..."
        killall -q ttyd &>/dev/null
        kill -QUIT $(cat $PID)
        # sleep 3
        wait_nginx_status
      fi
    }

    Doesn't solve the original problem :) but it should help make the rc.nginx more bulletproof.

    Link to comment
    1 hour ago, ljm42 said:

    I was looking at rc.nginx, what do you think of creating a wait_nginx_status function:

    
    wait_nginx_status() {
      while nginx_status; do 
        echo "Waiting..."
        sleep 1
      done
    }

     

    Sure we can do that, but with a timeout so as not hang shutdown, maybe something like this?

    wait_nginx_status() {
      for i in {1..10} ;do
        if [[ ! ngnix_status ]] ;then break ;fi
        sleep 1
      done
    }

     

    Link to comment
    1 minute ago, limetech said:

    Sure we can do that, but with a timeout so as not hang shutdown, maybe something like this?

    even better :) 

    Link to comment
    1 hour ago, limetech said:

    Sure we can do that, but with a timeout so as not hang shutdown, maybe something like this?

     

    Looks like this is the right syntax for the if statement, the double brackets didn't work:

    wait_nginx_status() {
      for i in {1..10} ;do
        if ! nginx_status ;then break ;fi
        sleep 1
      done
    }

     

    Link to comment
    33 minutes ago, ljm42 said:

    Looks like this is the right syntax for the if statement, the double brackets didn't work:

    This is what I went with because it matches the existing style in the file:

    wait_nginx_status() {
      for i in {1..10} ; do
        if ! nginx_status ; then
          break
        fi
        sleep 1
      done
    }

     

    • Like 1
    Link to comment

    Sorry... I was looking in rc.nginx for other places to use this, and I realized the function name should be more like wait_nginx_down instead of wait_nginx_status :) 

     

    It can easily replace the "sleep 3" in nginx_term and nginx_stop. But what about nginx_reload, is that actually waiting for nginx to be up instead of down? 

    Link to comment

    ok, happened again today

     

    i was testing some http api commands for tvheadend and one command stalled ... after that there was no more repsond, also could not quit the command at all, even a tvheadend restart (to definately kill the http connection) also didnt help, just as note.

     

    /etc/rc.d/rc.nginx restart <- worked then well here

    Link to comment



    Join the conversation

    You can post now and register later. If you have an account, sign in now to post with your account.
    Note: Your post will require moderator approval before it will be visible.

    Guest
    Add a comment...

    ×   Pasted as rich text.   Restore formatting

      Only 75 emoji are allowed.

    ×   Your link has been automatically embedded.   Display as a link instead

    ×   Your previous content has been restored.   Clear editor

    ×   You cannot paste images directly. Upload or insert images from URL.


  • Status Definitions

     

    Open = Under consideration.

     

    Solved = The issue has been resolved.

     

    Solved version = The issue has been resolved in the indicated release version.

     

    Closed = Feedback or opinion better posted on our forum for discussion. Also for reports we cannot reproduce or need more information. In this case just add a comment and we will review it again.

     

    Retest = Please retest in latest release.


    Priority Definitions

     

    Minor = Something not working correctly.

     

    Urgent = Server crash, data loss, or other showstopper.

     

    Annoyance = Doesn't affect functionality but should be fixed.

     

    Other = Announcement or other non-issue.