When I run a flow in Tableau Server, it fails with the following error message:
Unfortunately this error is not helpful in understanding the actual cause of the problem.
Is there a way to see the actual underlying error? Or how am I supposed to debug this?
The flow runs fine in my Tableau Prep.
(EDIT: I used state here that I used a different data source to test in prep, but this is no longer true)
Arguably that error log does give you a hint as to what the issue is. The issue is with the Output step. This is most likely due to a permissions error when Tableau Server goes to publish the output since you can do it locally in Tableau Prep.
Are credentials for your flows able to be embedded on server? This will impact whether the output will be accessible. Are all flows run using a service account? Make sure that service account has access to the output location.
If these troubleshooting steps don't work, check the server logs. For this you'll need to check the logs on Tableau Server using the command line to see if there is a more detailed response. If you have the access, run tsm maintenance ziplogs to zip the log files and investigate.
Related
We have been running a service using NestJS and TypeORM on fully managed CloudRun without issues for several months. Yesterday PM we started getting Improper path /cloudsql/{SQL_CONNECTION_NAME} to connect to Postgres Cloud SQL instance "{SQL_CONNECTION_NAME}" errors in our logs.
We didn't make any server/SQL changes around this timestamp. Currently there is no impact to the service so we are not sure if this is a serious issue.
This error is not from our code, and our third party modules shouldn't know if we use Cloud SQL, so I have no idea where this errors come from.
My assumption is Cloud SQL Proxy or any SQL client used in Cloud Run is making this error. We use --add-cloudsql-instances flag when deploying with "gcloud run deploy" CLI command.
Link to the issue here
This log was recently added in the Cloud Run data path to provide more context for debugging CloudSQL connectivity issues. However, the original logic was overly aggressive, emitting this message even for properly working CloudSQL connections. Your application is working correctly and should not receive this warning.
Thank you for reporting this issue. The fix is ready and should roll out soon. You should not see this message anymore after the fix is out.
I have a BizTalk 2013r2 Standard Edition application server with CU7 installed. The BizTalk databases are hosted on a separate Sql Server 2014 server. This setup has been working fine for many months - until today! A colleague used the BizTalk admin console to make a change to the address BizTalk uses to the reach the SMTP server, by selecting Platform Settings\Adapters\SMTP\\properties.
After making this change, on attempting to refresh the BizTalk Admin Console, the following error is displayed:
From what I've googled, it seems this may be due to some corruption in the SSO database. I have a backup of the SSO database, and a backup of the SSO key along with the password. Before restoring the backup of the SSO database, I wanted to check that I would be able to restore the key, so I ran ssoconfig -restoreSecret from the command line. I was prompted to enter the password. If I intentionally enter the wrong password then it tells me the password is incorrect. However, if I enter the correct password then it displays the message "BAD DATA".
Although the BizTalk admin console is currently unusable, thankfully the BizTalk host instance continue to run and messages are being processed as expected.
Can anyone please suggest why I'm getting the "BAD DATA" message, or perhaps a work-around in order to solve the problem?
I had this problem again and blogged about it at BizTalk WinMgt error solution. As Colin says the hard part is identifying the corrupt handler. It is probably the SMTP send handler but you should check this using WBEMTEST first. I found this link helpful on using WBEMTest. The parameter is incorrect (WinMgt)" error when refreshing the BizTalk Group in BizTalk Administration Console
In my case a quick fix to bring the BizTalk Administration Console back to life was to hack the database. N.B. This probably won't be supported by MS. In my case it was the FTP send handler that screwed up. So I ran
USE [BizTalkMgmtDb]
GO
DECLARE #return_value int
EXEC #return_value = [dbo].[adm_SendHandler2_Delete]
#AdapterName = N'FTP',
#HostName = N'Sending32'
SELECT 'Return Value' = #return_value
GO
At this point the BizTalk Administration console came back to life. In my case it worked because I was creating a new handler but in your case you just edited it. It will take all your SMTP handling out.
I then fixed the corruption using the BizTalk Administration console.
In my case I had to set every FTP receive and send adapter temporarily to a FILE adapter.
I then deleted the FTP adapter and then re-added it. Finally I reset the all the change receive and send location from FILE back to FTP.
This was all very scary on a live system.
Finally I believe that this is bug in BizTalk 2013 R2 because I've seen it happen on 2 systems and now I have heard that the same thing happened to you.
The WinMgt error happens when one of the Adapters setting has gotten itself corrupted. See WinMgt error when refreshing Group Hub
Removing and re-adding the adapter to the host usually fixes it. The trick of course is identifying which Adapter / Host, I would start with the SMTP adapter in your case.
I am using Web IDE and want to see the log by clicking on the arrow.I can only see an empty "Untitled" page. The Node.js app is running normally. Live edit is switch off.
After some minutes:
Gateway Timeout
The proxy server did not receive a timely response from the upstream server.
Reference #1.45bf1402.1511018717.3dddb8b
I'm not for sure what Web IDE you are referring to. The only one I'm aware of is the DevOps (which works for me below):
It seems to me like this error that you posted would indicate a temporary outage. Is it still an issue?
In any case, I would advise opening a support ticket if you encounter this issue again (more details about your account would help). I think the Bluemix proxy will time out requests if they take too long.
Yesterday our extracts failed to refresh with the following message (image extract_error):
Failure: Failed 1 time. Sign in failed.
Resolution Details: Check the Data Connection page for necessary updates to an access token or embedded credentials.
I verified that all our passwords were unchanged and test connections which were successful.
The tableau dashboards now give an error message saying:
HTTP 404:
Unable to connect to the server "localhost". Check that the server is running and that you have access privileges to the requested database. (image tableau_error)
Further, when I opened the Server Status page, I saw that our one of our two Vizql, backgrounder and data servers were down. We have two of each and only one of them is active for all three of them. (image server_status)
So, I decided to remote desktop into the server and run the tabadmin status -v command and strangely it is showing that all processes are running. (image tabadmin_status)
Finally, I opened a case with Tableau Customer Portal and letting them know about this issue (they asked me send them the log.zip file) but the mean time I was trying to problem solve this issue. Any help would be really appreciated.
After trying a lot of things, one process seemed to work.
Stopped the tableau server
Configured it to run 1 Vizql server process instead of 2
Started the server again
Finally, it worked. The status page now shows all the processes are active.
Hopefully, this helps someone who is facing a similar problem.
This may be caused by a firewall issue. Since tabadmin status -v returned all as "running" the cluster is healthy and this is a false alert. The firewall rules could be allowing just the first port and not the entire range (see https://onlinehelp.tableau.com/current/server/en-us/ports.htm) to respond to requests from the application server to build that fancy table with the green and red boxes.
The firewall can be reverted/altered behind the scenes for a number of reasons, usually windows updates or regular group policy synchronization.
Try disabling the windows firewall (https://www.faqforge.com/windows-server-2016/turn-off-firewall-windows-server-2016/), or add an inbound rule allowing access to all ports if your org policy doesn't allow you to actually turn it off. (Follow the steps here, except use "All Local Ports" instead of "Specific Local Ports" https://www.parallels.com/blogs/ras/configuring-windows-server-firewall-for-parallels-ras/)
I had a similar problem and followed these similar steps that Sravee mentioned above to bring the all processes back to active.
Stopped the server
Change the configuration for VizQL server from 2 to 1
Started the server
Enter the licence key (else the server status page will show unlicensed error)
Note: This does not bring the site back but this step is for 'tricking' VizQL server
Stopped the server again
Change the VizQL configuration from 1 to 2 now.
Start the server
Enter the license key
This steps did bring back the server back to active for us. Posting to see if this helps who faces the same problem. Thank you so much.
How can I get log information from PostgreSQl server?
I found ability to watch it in pgAdmin Tolls->ServerStatus. Is there a SQL way, or API, or consol way, to show content of log file(s)?
Thanks.
I am command line addict, so I prefer “console” way.
Where you find logs and what will be inside those depends on how you've configured your PostgreSQL cluster. This the first thing I change after creating a new cluster, so that I get all the information I need and in the expected location.
Please, review your $PGDATA/postgresql.conf file for your current settings and adjust them in the appropriate way.
The adminpack extension is the one providing the useful info behind pgAdmin3's server status functionality.