We record our office IP phone activity using Xima software's Chronicall, which uses a PostgreSQL backend. The server on which both of these are installed is an ESXi 5.5 VM running Windows Server Standard 2008 SP1. For some time now, we have been getting the following PostgreSQL errors in Windows event viewer:
"FATAL: could not reattach to shared memory (key=248,
addr=02510000): 487"
"WARNING: worker took too long to start; cancelled"
These errors occur every hour or two, and always occur back-to-back in the order listed above.
Xima support has looked at the issue multiple times and has not been able to resolve it. Upon their recommendation, I have upgraded Java, disabled antivirus, and run the Windows Memory Diagnostic Tool (came back clean), but the errors persist. Xima has specifically stated that PostgreSQL should not be updated, as versions above 8.3.7 are known to cause other issues with Chronicall.
Any other suggestions to resolve this issue?
I would say the company (Xima) is at fault here, since PostgreSQL 8.3.7 is hopelessly outdated.
Quoting the official Versioning policy of Postgres:
Postgres 8.3 has reached EOL in Februar 2013
Moreover, Postgres strongly recommends:
We always recommend that all users run the latest available minor
release for whatever major version is in use.
The latest point release of 8.3 is 8.3.23.
Version 8.3.7 is just not right.
Running Postgres on a Windows Server 2008 VM wouldn't be my first idea either...
Related
i am using Operations Manager 2016 for monitoring a host with Solaris 11.4 OS.
after several hours (24 h), host state is changed to gray and i get this text "The Run As account does not exist on the UNIX/Linux Server. " but Run As account is valid.
This problem is fixed each time by reset SCOM agent on host. I get this error over and over again.
also service log in /var/svc/log/application-management-omid:default.log is normal.
thanks.
I finally found the solution to this problem.
In my case, this problem is due to the lack of a lsass.so library in the system.
The problem was resolved after updating this library and modifying the PAM Configuration file.
thanks.
Looking for any thoughts on what is going on here:
Environment:
Java 11 GCP Function that copies data into table
Postgres 11 Cloud SQL using JDBC driver
(org.postgresql:postgresql:42.2.5)
No changes to any code or configuration in 2 weeks.
I'm connecting to the private SQL IP address, so similar to
jdbc:postgresql://10.90.123.4/...
I'm not requiring a SSL cert
There is Serverless VPC Access set up between the Function and SQL.
This is happening across two different GCP projects and SQL servers.
Prior to this Saturday (2/22), everything was working fine. We are using Postgres' CopyManager to load data into a table: copyManager.copyIn(sql, this.reader);
After 2/22, this started failing with "SSL error: DATA_LENGTH_TOO_LONG" as seen in the SQL server log. These failures are 100% consistent and still happen. I can see that SQL was restarted by Google a few hours before the issue started and I'm wondering if this is somehow related to whatever maintenance happened, SQL version upgrade? I'm unclear what version we had before Saturday, but it's now 11.6.
Interestingly enough, I can avoid the error if the file loaded into the table is under a certain size:
14,052 bytes (16 KB on disk): This fails every time.
14,051 bytes (16 KB on disk): This works every time.
I'd appreciate if someone from Google could confirm what took place during the maintenance window that might be causing this error. We are currently blocked by this as we load much larger datasets into the database than ~14 000 bytes.
FYI this was caused by a JDK issue with TLS v1.3, addressed in JDK 11.05. Google will likely upgrade the JDK used for the Cloud Functions JVMs from 11.04 to something newer next week. See https://bugs.openjdk.java.net/browse/JDK-8221253
I wonder because running it on a client's minidump it reports a different Windows version than the client repeatedly told me she had, and the version I'm being reported happens to be exactly the same version I'm running WinDbg on.
So I wonder, can vertarget always be trusted (and clients not) or the information it relies on may be absent with some dump generation options and when it is it reports the version WinDbg is currently running on, or maybe just some default that happens to coincide with my OS version?
I'm using WinDbg 6.12.
In all my cases so far, vertarget has been correct and the customer/client made a mistake - and vertarget is one of the commands I use for every dump, exactly for the purpose of checking if the dump contains what I need.
But perhaps, things can potentially go wrong here as well, so let's evaluate some options:
vertarget also reports debug session time and system uptime. Do those also match your system? Reboot your system in order to get a low system uptime and check again. Is it still your PC's uptime?
vertarget also reports the number of CPUs. Does that number match your number?
Get a virtual machine which does not have your OS, e.g. one from Modern.IE (Microsoft). Copy WinDbg and the dump to the VM and check the output of vertarget again.
WinDbg 6.12 is a bit old. Do newer versions (6.2.9200 / 6.3.9600 or even 10.0) provide the same information or was there a bug fixed already?
And even check some other information:
Is it a dump of the correct application? Use | (pipe)
Is it a dump of the version you are expecting? Use lm vm <exename>
Does it have the flags which can be expected for the method used for taking the dump? Use .dumpdebug.
Other than that I observe (not representative) that many client OS version dumps (Windows 7, 8, 8.1) have all latest service packs installed, while administrators seem to follow the "never change a running system" approach for server OS (Windows Server 2012, R2). So it might just be a coincident.
I'm having trouble starting a Couchbase 2.5.1 enterprise edition server process with Memcached buckets. I get a permanent "server down" message when I navigate to:
http://localhost:8091/index.html
The server logs just give this error for all the buckets I create.
[error_logger:error,2014-09-02T11:45:58.320,ns_1#127.0.0.1:error_logger<0.6.0>:ale_error_logger_handler:log_msg:119]** Generic server <0.2989.5> terminating
** Last message in was {'$gen_cast',
{connect_done,4,
{error,couldnt_connect_to_memcached}}}
** When Server state == {state,4,0,0,
{[{{stats,<<>>},
{<0.2341.0>,#Ref<0.0.8.143607>},
{1409,638548,233000},
2}],
[]},
{[],[]},
{[],[]},
connecting,undefined,"Customer",
still_connecting,undefined,[]}
** Reason for termination ==
** {bad_return_value,{stop,{error,couldnt_connect_to_memcached}}}
I'm running Windows 8.1 x64 and Couchbase 2.5.1. What's odd is that on another machine with the same setup, I can run Couchbase just fine. After searching on the Internet for a while, I found this link: http://irwinj.blogspot.in/2013/03/installing-couchbase-on-windows-8.html, but that's for Win8 + Couchbase 2. The referenced bug link says the issue has been fixed. So, I'm not sure what to do next next.
Any pointers would be great.
Thanks!
ps: If this question belongs to a different stack-exchange website, please let me know, I'll migrate the question there.
After upgrade our IBM System i (aka i5/OS or AS/400) from V5R4 to V7R1, one of our applications that connect to DB2 using ODBC fails with the following error:
Error Code: 69899
SQLSTATE: S1000
[IBM] [System i Access ODBC Driver] [DB2 for i5/OS] PWS0005
Error occurred in the database host server code.
The symptoms are:
In a While / Wend loop a CURSOR is declared, then opens, do fetch(s) and close.
If at any iteration the cursor does not retrieve any rows, in the following iteration the error occurs after declaring the cursor (with a different SQL query) when you try to open it.
First we updated the ODBC driver to the latest version available, but the problem persists.
Because we needed an urgent solution, I solved the problem by making a pre-select to determine if the cursor will return rows, otherwise skip that iteration, this solves the problem for now but does not seem a very elegant solution.
Any idea how to get more information about the error that occurs on the host?
Thank you very much in advance.
Generally speaking, if an error occurs in the server side code, you should call IBM support and report it. They'll ask if you're on the latest cume and probably the latest database group PTFs.
The server runs the ODBC connexion in a job called QZDASOINIT. Since there are probably many connexions to the system, there are probably many QZDASOINIT jobs. To find yours, go to a terminal session and WRKOBJLCK MYPROFILE *USRPRF. You'll be presented with a list of jobs running with your user profile. At least one of them will be the QZDASOINIT job you're looking for. Use option 5 to look at the job, then option 10 to see the job log. Press F10 to see the detailed messages and F18 to go to the bottom (most recent) entries.
If the error was so severe that the server job terminated abnormally, there won't be a lock on your user profile. Instead, go to the spooled job log by using WRKSPLF.
IBM have been logging some SQL internal errors since V5R4. select * from qrecovery.qsq901s; to see any SQLCODE -901 errors.
Make sure that you have installed the latest fix pack for the latest version of System I Access
I've had this error before and it was caused by a syntax error in the connection string. It was a setting that was insignificant in older versions of the OS and more significant in newer versions, but did not cause the connection itself to fail so it was hard to track down.
For example: Port Number:8471 had a spelling mistake and was Porte Number:8471 hard to spot but once found, it fixed the problem for me. Basically everything past this part of the connection got ignored.
Wanted to add another solution to this problem. The SQL Packages that exist on your system get corrupted after/and or during upgrades. You MUST delete these packages after an upgrade. This will get rid of the old packages and will allow the system to recreate the packages at the new OS version level. When deleting SQL packages some connections/jobs may have locks on those packages so you might have to shut host services down. Use the DLTSQLPKG command to do the delete. In v7r2 and higher there are some additional steps to do as IBM changed somethings when it comes to packages you can find the info here http://www-01.ibm.com/support/docview.wss?uid=nas8N1015556
Or tell your ODBC/JDBC/.Net Data adapter/provider to not use packages. This is probably less desirable as there are performance benefits to packages.