Web UI lockup

Web-UI
1

Running a fresh install of mineos, for some reason when ever I boot up my FTB Infinity server the webui always seems to lockup and freeze my whole browser/tabs etc.

I remember having this problem on a different machine in the past. But never did anything about it then. Now that iam back to hosting I would like to solve this problem if possible.

Any help much appreciated.

2

hi Ank,

this still happens to me with all my mc servers.

it seems while booting so many lines are generated in the webui console it locks up the browser somehow.

so what i do is select the server and press the start button then log out. wait a while and log back in. this works ok if the server has no issues.

it is a pain if the server hangs or fails to boot because you don’t know it.

i am confused why others do not report this problem and i had a thread opened myself asking, in the past. the solution offered did not work for me because i was to scared to try it, but might for you.

good luck!

tNt

3

To see if (and what makes) this happend you can use putty and the “tail” command.

  1. Open two (or more) separate putty SSH sessions to your MineOS server
  2. use one of the commands in each ssh window:
  • “tail -f /var/log/mineos.log” (to see the MineOS.log asit gets written to catch WebUI errors)
  • “tail -f /var/games/mineos/servers/(servername)/logs/latest.log” (or other logs detailing what your server does, since FTB may be using other logs to monitor).

If you wish to monitor more logsfile, just add another putty session.

If your server do not start, or crashes during startup, and while the WebUI is frozen, you should see what is happening from what is written in the logs.

To end a “tail -f” session, simply press [ctrl]-[c]

4

Thanks for your help guys, tried the ssh commands and when reading the output there were no errors.

5

tail -f /var/games/minecraft/servers/FTB_Infinity/logs/latest.log
[05:23:50] [Server thread/INFO]: Starting minecraft server version 1.7.10
[05:24:21] [Server thread/INFO]: Loading properties
[05:24:21] [Server thread/INFO]: Default game type: SURVIVAL
[05:24:21] [Server thread/INFO]: Generating keypair
[05:24:21] [Server thread/INFO]: Starting Minecraft server on 0.0.0.0:25565
[05:24:39] [Server thread/INFO]: Preparing level “world”
[05:24:41] [Server thread/INFO]: Preparing start region for level 0
[05:24:42] [Server thread/INFO]: Done (3.324s)! For help, type “help” or “?”
[05:30:14] [Server thread/INFO]: No hostile mobs found!
[05:30:14] [Server thread/INFO]: Killed 5 of type net.minecraft.entity.item.Enti tyItem
[05:39:44] [Server thread/INFO]: Saving…
[05:39:44] [Server thread/INFO]: Saved the world

6

tail -f /var/log/mineos.log
{“level”:“info”,“message”:"[FTB_Infinity] 192.168.1.80 issued command : “modify_sc”",“timestamp”:“2017-08-26T05:23:43.101Z”}
{“level”:“info”,“message”:"[FTB_Infinity] received request “modify_sc”",“timestamp”:“2017-08-26T05:23:43.104Z”}
{“level”:“info”,“message”:"[FTB_Infinity] 192.168.1.80 issued command : “modify_sc”",“timestamp”:“2017-08-26T05:23:45.389Z”}
{“level”:“info”,“message”:"[FTB_Infinity] received request “modify_sc”",“timestamp”:“2017-08-26T05:23:45.390Z”}
{“level”:“info”,“message”:"[FTB_Infinity] 192.168.1.80 issued command : “start”",“timestamp”:“2017-08-26T05:23:46.569Z”}
{“level”:“info”,“message”:"[FTB_Infinity] received request “start”",“timestamp”:“2017-08-26T05:23:46.570Z”}
{“level”:“info”,“message”:"[WEBUI] mc connected from 192.168.1.80",“timestamp”:“2017-08-26T05:33:32.878Z”}
{“0”:“de_DE”,“1”:“en_US”,“2”:“fr_FR”,“3”:“it_IT”,“4”:“ja_JP”,“5”:“no_NB”,“6”:“ru_RU”,“7”:“sv_SE”,“level”:“info”,“message”:"",“timestamp”:“2017-08-26T05:33:32.884Z”}
{“level”:“info”,“message”:"[FTB_Infinity] mc (192.168.1.80) joined server namespace",“timestamp”:“2017-08-26T05:33:34.163Z”}
{“level”:“info”,“message”:"[FTB_Infinity] transmittting existing file contents: logs/latest.log (660 bytes)",“timestamp”:“2017-08-26T05:33:34.404Z”}

7

MineOS attaches to minecraft-created logs, and server packs like these do a particularly excellent job at producing an enormous amount of loglines.

MineOS can’t (or won’t) determine which log lines to send, it sends them all. This can, depending on the server type, mean thousands of lines in a very short period of time.

The webui attempts to curb any crashing by seeing if 160 lines in 2 seconds gets flooded in (and it happens), and that kind of log traffic really bogs down the browser (think of it like: the size of your log literally just gets added to the amount of memory your browser needs).

The rate-limiting is only a half-measure; it helps reduce the browser’s likelihood of using up all your desktop’s memory and slowing it down to a crawl, to the point where it crashes. On the other hand, the log file continues to generate tons of logs and the backend continues to transmit it. This transmission has a little cost, though it’s dwarfed by the performance cost of actually displaying it.

Linked above, you can see a workaround that actually just removes a given logfile from the webui (but more accurately, it removes it from being tailed on the MineOS backend). This solution actually solves both ends of the problem, which is the tailing memory/performance cost and the transmission to the browser (mem/perf costs). It also makes it so that particular file isn’t browsable in the webui.

So it’s a tradeoff. If the value of the logs is marginal, remove it from tracking and you’ll have all the performance reclaimed. Otherwise, just wait for an amount of time when the servers no longer produce excessive logs, and then refresh (re-enabling tailing)