Since recently some java applications started to print the following warnings every now and than:
java.util.prefs.FileSystemPreferences syncWorld
WARNING: Couldn't flush user prefs: java.util.prefs.BackingStoreException: /home/yha/.java/.userPrefs/_!(k![#"k!'`!~!"p!(#!bw"y!#4![!"v!':!d#"t!'`!bg"0!&#!e#"w!'`!ew"0!(k!c!"l!&:!d!"y!'k!bg"n!$0!,w"h!(!!c!"s!'k!}w"h!(#!a#"v!'4!.#"5!'}!a#"s!'`!cw!n!(0= create failed.
"create failed". No kidding! What kind of file name is that?
After googling I now know what the Java Preferences Subsystem is and that the default value for storage on Linux should be $HOME/.userPrefs or the like but... that does not explain where the path I have in my log message is coming from. And I still don't know where to set this value. Maybe there is a configuration file with the storage file path somewhere that became corrupt.
using openjdk-7 on Kubuntu 12.10
That whacky string is the result of a call to java.util.prefs.Base64.byteArrayToAltBase64(). if you reverse the process, you get: "yEdeditor.DocumentType{typeString='application-yfiles'}". does that string mean something to you?
the file name characters may not ultimately be the problem (they may be correct). if your ubuntu home directories are encrypted, you are most likely running into this "well known" issue (max file name length of 143 chars for files in encrypted filesystems). very subtle and extremely hard to diagnose bug.
Related
I am trying to synchronize two Firebird databases with each other. First of all, I already configured that the synchronization will be one-way. Therefore, one database is the Source-DB and the other is the target-DB.
To start a synchronization I use IBReplicator! When I start the synchronization, I get the error:
Exception: Invalid token
invalid request BLR at offset 340
function F_LRTRIM is not defined
module name or entrypoint could not be found
I started searching for the cause of the problem. What I already checked:
.dll files exist in the firebird directory
Firebird version is 32 - bit
IBExpert displays the UDF in the UDF Section of the database.
I read that it could be a problem when there is a mismatch between Firebird Server version and .dll file version. But I don't know how to verify the versions.
And I wanted to search for a .conf file to check the path for the UDF file (.dll) but I didn't find it. I only found the firebird.conf file and I already set the UDFAccess to Full.
I would really appreciate if someone could help me. I wasted a huge amount of time in this problem.
The error means that Firebird can't find the entrypoint or library when the function is executed. This means that
The library can't be found: it is not on the (library) path or in one of the folders listed in the UdfAccess configuration
The library was found, but it is 32 bit and you're running 64 bit (or it's 64 bit and you're running 32 bit)
The library was found, but doesn't have the entrypoint for the UDF.
Your problem seems to be the first, and the solution is to add the location of the UDF to the UdfAccess configuration. Given the comments, you should use
UdfAccess = Restrict UDF
Which will only allow UDF libraries from the UDF directory of your Firebird installation. If needed you can list multiple directories separated by ;.
You should never use UdfAccess = Full, it is unsafe as it can possibly be used to compromise your system with any library on the (library) path of your system.
I came across this error that is apparently pretty common among Linux Systems.
"Too many files Open"
In my code I tried to set the Python open file limit to unlimited and it threw an error saying that I could not exceed the system limit.
import resource
try:
resource.setrlimit(resource.RLIMIT_NOFILE, (500,-1))
except Exception as err:
print err
pass
So...I Googled around a bit and followed this tutorial.
However, I set everything to 9999999 which I thought would be as close to unlimited as I could get. Now I cannot open a session as root on that machine. I can't login as root at all and am pretty much stuck. What can I do to get this machine working again? I need to be able to login as root! I am running Centos 6 and it's as up to date as possible.
Did you try turning it off and on?
If this doesn't help you can supply init=/bin/bash as kernel boot parameter to enter a root shell. Or boot from a live cd and revert your changes.
After performing an 'strace su -', I looked for the 'No such file or directory' error. When comparing the output, I found that some of those errors are ok, however, there were other files missing on my problem system that existed on a comparison system. Ultimately, it led me to a faulty line in /etc/pam.d/system-auth-ac referencing an invalid shared object.
So, my recommendation is to go through your /etc/pam.d config files and validate the existence of the shared object libraries, or, look in /var/log/secure and it should give some clue to missing shared objects as well.
I'm trying to deploy the Sybase SQL Anywhere 10 Runtime Engine, but I'm having some problems. When I run my application, I get an error:
SQLSTATE = IM003
Specified driver could not be loaded due to system error 193 (cinema_ConfigurationDriver).
According to my research, this is indicative of a missing DLL. I am looking at documentation on what and how to deploy. That documentation is from the Sybase SyBooks Online site
I have copied the indicated file into my application directory. I have also created the registry entries as indicated with two changes. Instead of calling the driver SQL Anywhere 10.0 I have called it cinema_ConfigurationDriver.
And I did not create the DSN entry; I am using a DSN-less connection in my PowerBuilder 11.5 code.
I know zilch about PowerBuilder, and I have no idea what "cinema" refers to, but I do know that there are no error messages in SQL Anywhere that contain "cinema". However, "Unable to start specified database" is definitely a SQL Anywhere error message. Can you post the full contents of your connection string? (You can either update your question or add a comment to this answer.)
Edit after OP comment:
You don't need to specify the -ga switch, since the client library will add it for you (unless you use the AUTOSTOP=NO connection parameter), and you shouldn't add the -n switch to the START line, since that's what the ENG parameter is for. Neither of these will cause your problem however. The obvious thing to check is that you've specified the correct path to the .db file and that you have permission to modify the file. If that's OK, you could add the LOG=<filename> parameter to the connection string, and then check the contents of that file for more detailed information.
The MS source server technology uses an initialization file named srcsrv.ini. One of the values identifies the source server location(s), e.g.,
MYSERVER=\\machine\foobar
The docs leave much unanswered about this value. To start with, I haven't been able to find the significance of the value name, i.e., what's on the left side--and I don't see it used anywhere else. Hewardt & Pravat in Advanced Windows Debugging say "The left side ... represents the project name", but that doesn't seem to jibe with MS's "MYSERVER" example.
What is the significance of the left side? Where else is it used? Does the value reference a server or a project, and is there one per server, or one per project?
For anyone looking into this in the future, I received the following information from MS:
The name on the left side is the logical name of a version
control server. The name is also used in the source-indexed symbol files
(pdb). For example, a symbol file may contain this string value: MYSERVER=mymachine1.sys-mygroup.corp.microsoft.com:2003and the source files are referenced like this in pdb: *MYSERVER*/base/myfolder/mycode.cWhen SrcSrv starts, it looks at Srcsrv.ini for values; these values override the information contained in the .pdb file: "MYSERVER=mymachine.sys-mygroup.corp.microsoft.com:1666" overrides
"MYSERVER=mymachine1.sys-mygroup.corp.microsoft.com:2003"This enables users to configure a debugger to use an alternative source control server at debug time. The info is documented at http://msdn.microsoft.com/en-us/library/ms680641.aspx.
So, it is a logical name for a source server, and its value can be changed at debug time to reference a different server than the one originally used when the PDBs were created.
The way the debugger retrieves your source is by srcsrv using some command line utility. The utility program itself and the command line used varies depending on which type of repository hosts your code. One of the issues preventing retrieval is that when that command line program is invoked it fails.
To find out why use the command !sym noisy in WinDBG. It is mostly helpful in diagnosing symbol server issues but for source indexed PDB it also will show the actual command line WinDBG used. Copy the command from the command log window and run it in CMD.EXE to get more details on the failure.
I've moved a WebBBS board from one server to another. Ever since the board doesn't work.
I'm getting an Apache error whenever I try to access the board. Don't even know where to start the debugging, I'm not a Perl person. The file paths remained the same and there isn't any DB involved.
http://gammonline.com/members/board/
Any ideas?
After a bit of testing I believe that the problem has something to do with the index.cgi which is located in that folder (not getting the error when renaming it).
Thanks,
Roy.
More information about this error may be available in the server error log.
Says it all. You will have to find the error log and look at it.
If you are using CGI, the first step is to check you have given it the right permissions so it is an executable script at all.
chmod 755 index.cgi
This is caused by Apache config errors. Set LogLevel debug and tail -f the error log. It will probably be something to do with .htaccess permission for override, or, it's requiring a module which isn't loaded. The error log will tell you instantly.