After starting, stopping, or restarting any server, the browser tab of the UI stops responding and eventually asks me to kill the page process.
The Chrome Dev Console reveals somewhere around 15-20 instances per second of: “TypeError: Cannot read property ‘max-players’ of null”, and the number of errors approaches 4000 before the tab runs out of memory and stops responding:
That was my first thought, but all of them are integers (20). On further inspection, the error count immediately starts rising from page load, regardless of server actions.
Here is the complete Chrome console output:
4angular.js:12798 TypeError: Cannot read property 'max-players' of null
at server_model.<anonymous> (scriptin.js:346)
at Function.each (jquery-2.1.4.min.js:2)
at n.$scope.player_capacity (scriptin.js:344)
at Array.fn1 (eval at compile (angular.js:13643), <anonymous>:4:944)
at angular.js:14685
at n.$digest (angular.js:16209)
at n.$apply (angular.js:16482)
at HTMLAnchorElement.<anonymous> (angular.js:24098)
at HTMLAnchorElement.dispatch (jquery-2.1.4.min.js:3)
at HTMLAnchorElement.r.handle (jquery-2.1.4.min.js:3)
(anonymous) @ angular.js:12798
21angular.js:12798 TypeError: Cannot read property 'max-players' of null
at server_model.<anonymous> (scriptin.js:346)
at Function.each (jquery-2.1.4.min.js:2)
at n.$scope.player_capacity (scriptin.js:344)
at Array.fn1 (eval at compile (angular.js:13643), <anonymous>:4:944)
at angular.js:14685
at n.$digest (angular.js:16209)
at n.$apply (angular.js:16482)
at Socket.<anonymous> (scriptin.js:914)
at Socket.Emitter.emit (socket.io.js:7414)
at Socket.onevent (socket.io.js:7130)
(anonymous) @ angular.js:12798
2angular.js:12798 TypeError: Cannot read property 'max-players' of null
at server_model.<anonymous> (scriptin.js:346)
at Function.each (jquery-2.1.4.min.js:2)
at n.$scope.player_capacity (scriptin.js:344)
at Array.fn1 (eval at compile (angular.js:13643), <anonymous>:4:944)
at angular.js:14685
at n.$digest (angular.js:16209)
at n.$apply (angular.js:16482)
at HTMLSelectElement.<anonymous> (angular.js:29216)
at HTMLSelectElement.dispatch (jquery-2.1.4.min.js:3)
at HTMLSelectElement.r.handle (jquery-2.1.4.min.js:3)
(anonymous) @ angular.js:12798
29angular.js:12798 TypeError: Cannot read property 'max-players' of null
at server_model.<anonymous> (scriptin.js:346)
at Function.each (jquery-2.1.4.min.js:2)
at n.$scope.player_capacity (scriptin.js:344)
at Array.fn1 (eval at compile (angular.js:13643), <anonymous>:4:944)
at angular.js:14685
at n.$digest (angular.js:16209)
at n.$apply (angular.js:16482)
at Socket.<anonymous> (scriptin.js:914)
at Socket.Emitter.emit (socket.io.js:7414)
at Socket.onevent (socket.io.js:7130)
(anonymous) @ angular.js:12798
486angular.js:12798 TypeError: Cannot read property 'max-players' of null
at server_model.<anonymous> (scriptin.js:346)
at Function.each (jquery-2.1.4.min.js:2)
at n.$scope.player_capacity (scriptin.js:344)
at Array.fn1 (eval at compile (angular.js:13643), <anonymous>:4:944)
at angular.js:14685
at n.$digest (angular.js:16209)
at n.$apply (angular.js:16482)
at Socket.<anonymous> (scriptin.js:914)
at Socket.Emitter.emit (socket.io.js:7414)
at Socket.onevent (socket.io.js:7130)
The last message in the above train is the error spammed into the console.
Aha, so the web UI expects a server.properties file to exist in every server directory, and contains no error-checking in the event there isn’t one; but rather, returns null. In my case, a non-server directory named tmpdir was the culprit (oddly enough, I don’t remember creating it.)
A quick grep of the log file showed nothing indicating a problem. Should that be the case?
A server.properties file gets created in any directory that MineOS creates, but I think we’re looking at something even more specific.
For example, you can create a directory in /var/games/minecraft/servers called tmpdir and the webui will gracefully ignore it. You can follow up by creating server.properties in that directory, and the webui will detect it. And then the errors cropped up after deleting server.properties but not yet refreshing the server list in the webui.
The problem we’re running into was a client-side issue where evidently the server-side found a server.properties and decided to send its file contents to the client. The client, however, looked at the “contents” and didn’t find max-players. The huge count of errors is a client side I’ll make a commit for right now, but I’d much rather detect this on the server side first (so that it can prompt the user or log it, rather than just go on with it’s work).
TL;DR: I believe that tmpdirhad a server.properties file, but it was deleted. Though it was deleted, the server-side wasn’t refreshed (via “refresh server list” or restarting the webui daemon). Working on a commit to fix it now.
That would make sense; after thinking back for a bit, I now remember extracting Forge to the temporary dir while setting up an FTB private pack. I must have run rm -rf on the tmp folder while it had open files, preventing it from deleting entirely (while still removing server.properties). That’s what I get for not paying attention!
Also good to know that the ./server folder isn’t re-scanned automatically on WebUI load. For some reason I thought Refresh Server List was client-side only, basically equivalent to refreshing the page. I think renaming it to Rescan Servers Folder would make a bit more sense.
Alright, so this issue was even milder than I could have imagined. The only problem here was that the circular “players online” gauge on the dashboard required the max-players for determining how far to fill the bar.
Everywhere else, deleting the server.properties file was handled gracefully and without any actual issues. Extra dumb the webui was brought to its knees by such a low criticality visual! No Refresh Server List necessary at all.
