Hi Bogdan. What happens when you do a "tabadmin status -v" ? Does it show that all processes are in a running state? Also, what is the clock speed of the CPU that you are running?
Yes, "tabadmin status -v" shows that all the processes are running.
The host machine has 2 CPUs, each CPU has 8 Cores / 16 Threads, so a total of 16 Cores / 32 Threads.
The CPU base frequency is 1.8 GHz and the maximum Turbo frequency is 2.9 GHz.
So is it all functionality working. It could be that there is a lag in the actual startup of all the services, so that's why you see the error. I encountered some similar errors on my dev environment when upgrading to 10.5, but ultimately all functionality was there, and when I upgraded prod that had a higher clock speed, there were no errors.
Well no, even though "tabadmin status -v" shows that all the processes are running tableau is not accessible from the browser as nothing is rendering.
When trying to access http://127.0.0.1./admin/systeminfo.xml again nothing is loading.
So as long as this message "Unable to determine if all components ..." is given when you run "tabadmin start" the instance is not accessible.
As I said, following the procedure from here: Unable to Determine if All Components of the Service Started Properly - Help Analysing the Log File seems to solve the problem but this doesn't mean that is normal.
It definitely doesn't seem normal. How much RAM is on there?
The host has 256GB RAM and SSD storage
So, I just reproduced this on Tableau Server 2018.1.3.
These are the details:
1. I installed from scratch Tableau Server 2018.1.3
2. I applied the settings, started the service, navigate on the browser, all is good
3. stopped tableau, restored the most recent back-up from version 10.4.3, then when I execute tabamin start I got the same issue
4. even though I got the message "Unable to determine if all components of the service started properly" when I run tabadmin status -v shows that all the processes are running - please see the attached image
5. http://localhost is blank
6. accessing http://127.0.0.1/admin/systeminfo.xml loads for ever, so nothing appears
And you have enough disk space on SSD after the restore?
Yes, the free space on D is 1.01TB from a total of 1.09TB
It's hard to know what's going on then, I don't see any red flags. Do you have the ability to submit a support case? This may be your best option for deeper investigation. Also, you will want to ensure nothing else is running on this server, and that anti-virus exclusions are established and that ports aren't somehow being blocked. Sorry I can't be of more help.
As long as Tableau 10.4.3 was running fine on the same host from months, the same should be happening with 2018.1.3. This is one of the dedicated nodes and no other application is running, no antivirus either.
I notice this time that in tabadmin.log from version 2018.1.3 there are more details and these 2 sections come to my attention:
IMPORTANT: Command executed successfully.
However, "netsh firewall" is deprecated;
use "netsh advfirewall firewall" instead.
For more information on using "netsh advfirewall firewall" commands
instead of "netsh firewall", see KB article 947709
Second one, there are multiple lines with "Waiting for component on 8600 to become ready by requesting " and then:
2018-07-13 15:32:31.172 +0000_DEBUG_10.5.2.232:tableau002-par_:_pid=21864_0x2c7106d9__user=__request=__ Gave up on with_vizportal_ready or with_sitesaml_ready, Tableau Server not available; check that it is running. file:/D:/Tableau Server/2018.1/bin/tabadmin.jar!/lib/service.rb:2060:in `with_component_ready'
file:/D:/Tableau Server/2018.1/bin/tabadmin.jar!/lib/service.rb:2019:in `with_vizportal_ready'
file:/D:/Tableau Server/2018.1/bin/tabadmin.jar!/lib/service.rb:1391:in `start'
file:/D:/Tableau Server/2018.1/bin/tabadmin.jar!/lib/service.rb:1384:in `start'
file:D:/Tableau Server/2018.1/bin/tabadmin.jar!/lib/service/service_runner.rb:33:in `start'
file:/D:/Tableau Server/2018.1/bin/tabadmin.jar!/lib/commands/start.rb:36:in `run'
file:/D:/Tableau Server/2018.1/bin/tabadmin.jar!/lib/multicommand.rb:255:in `dispatch'
file:/D:/Tableau Server/2018.1/bin/tabadmin.jar!/bin/tabadmin.rb:35:in `(root)'
file:/D:/Tableau Server/2018.1/bin/tabadmin.jar!/bin/tabadmin.rb:1:in `(root)'
file:/D:/Tableau Server/2018.1/bin/tabadmin.jar!/META-INF/main.rb:36:in `require'
2018-07-13 15:32:31.172 +0000_DEBUG_10.5.2.232:tableau002-par_:_pid=21864_0x2c7106d9__user=__request=__ Tableau Server not available; check that it is running.
2018-07-13 15:32:31.172 +0000_INFO_10.5.2.232:tableau002-par_:_pid=21864_0x2c7106d9__user=__request=__ Unable to determine if all components of the service started properly. See "tabadmin.log" for more information.
I'll see if I can open a support case.
Our IT department installed the weekly Windows Server 2008 R1 patches this weekend and now none of our three servers will tabadmin stop cleanly which means they won't tabadmin start, no way to kill the process even with the process ID, something is holding onto a handle, we have to restart Windows. This is affecting 10.4.7, 10.4.8, and 2018.1.3. The process in question is httpd.exe, the Apache server, which is being started by Tableau Server, For the first time in 7 years tabadmin stop won't kill all the tableau server processes.
===== Starting service...
*** Tableau Server Gateway requires port 80,
*** in use by process 2192.
*** Tableau Server unable to start due to blocked ports.
===== Unable to determine if all components of the service started properly. See
"tabadmin.log" for more information.
Here's another recent thread suggesting that after a Windows or anti-virus update another process can steal the default Tableau Server gateway port 80 but that doesn't quite fit what I'm seeing with tabadmin stop leaving a few processes not killed or killable even with taskkill etc. I will ask IT to look into that possibility however.
There is no antivirus and no recent windows updates installed on our host.
I encounter this issue only after I restore a back-up from tableau 10.4.3 on tableau 2018.1.3. The restoration process is executed using the --no-config option.
We'd been doing that exact same restore every night (10.4.X -> 2018.1.X) without problems until this weekend. That command fails for us now but so does the simpler tabadmin stop followed by tabadmin start. See if that still works on your 2018.1.3 server. We get the error I posted above and have to restart Windows.