recently I upgraded puppet agent from 6.25 to 6.26 on the puppetserver and it seems that after upgrade all agents conected to the puppetserver fail to apply changes due to an internal server error caused by versioncmp() built in function.
The quick fix to keep going is to downgrade puppet agent on the server to 6.25
Error:
Could not retrieve catalog from remote server: Error 500 on SERVER: Server Error: Evaluation Error: Error while evaluating a Resource Statement, Evaluation Error: Error while evaluating a Function Call, wrong number of arguments (given 3, expected 2)
Anyone managed to find where it breaks, and how versioncmp is changed in such manner that it sees 3 arguments?
Note: The function worked perfectly before and I did not changed anything in code.
Many thanks
Please see https://tickets.puppetlabs.com/browse/PA-4189 for details. You need to make sure that the puppetserver package is updated as well.
The error message says that one of your manifests attempts to pass three arguments to the built-in versioncmp() function, which takes only two arguments (and never has taken more). Chances are excellent that the message is correct, and that change from Puppet 6.25 to 6.26 is that the latter now fails catalog compilation when the wrong number of arguments are passed, whereas the former did not. Possibly you would see warnings in the catalog compiler's logs from earlier.
Very likely, then, the correct solution is to find the bad function call and fix it. Certainly finding the function call that Puppet is complaining about is key to moving forward in any case.
Related
Why did I get below error? This error doesn't always happen. It occurred only once. This error came from ResultSet.next(). I am doing some research about it but I couldn't find the main reason. Here is the link that I found for same SLQCODE and SQLSTATE.
DB2 SQL Error: SQLCODE=-1476, SQLSTATE=40506, SQLERRMC=-293, DRIVER=3.63.123
at com.ibm.db2.jcc.am.fd.a(fd.java:666)
at com.ibm.db2.jcc.am.fd.a(fd.java:60)
at com.ibm.db2.jcc.am.fd.a(fd.java:127)
at com.ibm.db2.jcc.am.vn.b(vn.java:4031)
at com.ibm.db2.jcc.t4.db.h(db.java:286)
at com.ibm.db2.jcc.t4.db.a(db.java:244)
at com.ibm.db2.jcc.t4.db.c(db.java:31)
at com.ibm.db2.jcc.t4.r.a(r.java:32)
at com.ibm.db2.jcc.t4.j.Zb(j.ja
DB2 version: DB2 v10.1.0.4
OS: Linux
The underlying error (that caused the rollback) is the -293, which corresponds to SQL0293N (error accessing container). You need to check the details at this link of the documentation.
Don't ignore this error-message, you want to find root cause, from database diagnostics files.
It may be that the issue is only with one specific container that gets occasionally accessed. Or it may have been a temporary issue according to how the container is implemented (file-system, raw, san, device etc).
If your Db2-server has good alerting at operating-system, file-system, and Db2-level then there may have been alerts about the underlying issue.
If the Db2-server runs on Linux/Unix/Windows, then search in the diagnostics files for references to the -1476 and then find other preceding messages. That usually gives more details. You can use the timestamp of the error message to narrow down the diagnostics location where you may find more details. If you find that information, edit your question to include it. You might also add details of the Db2-server version and the operating system on which it runs.
I'm having this weird issue: I have a program that uses CUPTI callbackAPI to monitor the kernels in the program. It runs well when it's directly launched; but when I put it under cuda-gdb and run, it failed with the following error:
error: function cuptiSubscribe(&subscriber, CUpti_CallbackFunc)my_callback, NULL) failed with error CUPTI_ERROR_NOT_INITIALIZED
I've tried all examples in CUPTI/samples and concluded that programs that use callbackAPI and activityAPI will fail under cuda-gdb. (They are all well-behaved without cuda-gdb) But the fail reason differs:
If I have calls from activityAPI, then once run it under cuda-gdb, it'll hang for a minute then exit with error:
The CUDA driver has hit an internal error. Error code: 0x100ff00000001c Further execution or debugging is unreliable. Please ensure that your temporary directory is mounted with write and exec permissions.
If I have calls from callbackAPI like my own program, then it'll fail out much sooner with the same error:
CUPTI_ERROR_NOT_INITIALIZED
Any experience on this kinda issue? I really appreciate that!
According to NVIDIA forum posting here and also referred to here, the CUDA "tools" must be used uniquely. These tools include:
CUPTI
any profiler
cuda-memcheck
a debugger
Only one of these can be "in use" on a code at a time. It should be fairly easy for developers to use a profiler, or cuda-memcheck, or a debugger independently, but a possible takeaway for those using CUPTI, who also wish to be able to use another CUDA "tool" on the same code, would be to provide a coding method to be able to disable CUPTI use in their application, when they wish to use another tool.
perl contrib/bz_webservice_demo.pl --uri http://bugzilla.example.com/xmlrpc.cgit always errs out with 500 Error for Bugzilla.version.
error.log show that
xmlrpc.cgi: Can't use an undefined value as a subroutine reference at lib/SOAP/Transport/HTTP.pm line 384
If I hit another well know server like bugzilla.redhat.com ; it shows version perfectly. That means this server problem and not client related.
Bugzilla version 4.4.6
Uname - Ubuntu 14
In this file: bugzilla/lib/SOAP/Transport/HTTP.pm, comment out lines 384 and 452. These lines both pass some value to a new debug_logger that didn't exist in the SOAP/HTTP module in my previous Bugzilla installation. Since we're not trying to debug this module, there is no need for those lines anyway.
It's worth pointing out that the SOAP module is not part of Bugzilla's own code, and is not included with the files you download. It gets installed during the setup process. This means it doesn't matter what Bugzilla version you're running. This is something that was changed in the SOAP module, so if you tried to reinstall an older version of Bugzilla, it wouldn't fix the problem.
I have exactly the same on Ubuntu14 and Fedora20 Bugzilla4.4.6 boxes.
"500 internal server error", no bugzilla/errorlog entries,
but /var/log/httpd/error_log shows
xmlrpc.cgi: Can't use an undefined value as a subroutine reference at lib/SOAP/Transport/HTTP.pm line 384.
The perl cgi script needs to be debugged right?
when i try to run the setup.exe to start the installation, i get the following error in windows_xp:
Microsoft .NET Framework CAS Policy Manager has encountered a problem and needs to close.
this is what is in the error signature:
AppName: caspol.exe AppVer: 2.0.50727.3053 AppStamp:4889dd08
ModName: mscorwks.dll ModVer: 2.0.50727.3607 ModStamp:4add5446
fDebug: 0 Offset: 000d0494
i have tried completely removing and reinstalling all of my .net installations and it didn't resolve the issue. it's weird, because one time i tried to run setup i got two application events but subsequent tries did not produce more events.
the first event's id is 1023:
.NET Runtime version 2.0.50727.3607 - Fatal Execution Engine Error (7A09795E) (80131506)
It might be possible that the uninstallation did not remove all objects such as registry keys.
This may be of some use but I cannot verify its success rate having not used it myself.
http://www.justanswer.com/computer/5gtob-microsoft-net-framework-cas-policy-manager-encountered.html
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.