i've got a problem with my local tuxedo instalation. My servers and services works fine but when i try to list them using psr (printserver) or printclient tmadmin response: pg: Can't get temp file for writing. Can you tell me where can i find possible issue ?
did you look at the error messages for tuxedo found in this location
http://docs.oracle.com/cd/E13203_01/tuxedo/tux71/pdf/cdtux_d.pdf
Problem was no space i /var mounted place.
It sounds like you're facing problem with the ULOG, have you setted up ULOGPFX and it address a location with the sufficient permissions?
Related
I've implemented MQSAgent before and it was working. Had to reinstall it on my server. First, the user/name and password are correct. The user is a member of the COM group. After I confingured it, it returns:
T22]:IMQSAgent.IsDataPresentEx() : Encountered NotImplementedException:
Reason: The method or operation is not implemented.
The Com service is started. Also checked DTS and everything looks correct.
I've never received this error before. Any suggestions? Thanks in advance.
Looks like there were two MQSAgent.dll files that were not the same, in the BizTalk Server directory. One had a file size 90KB and the other 199KB. Not sure how these were in the directory both as MQSAgent.dll. Deleted the 90KB file and MQSAgent is now posting messages on MQ.
I am using elasticsearch in a liferay portal (sidecar). Unfortunately, elasticsearch can only be startet as root user. Otherwise, I get a java native error in
org.elasticsearch.bootstrap.JNANatives.trySetMaxNumberOfThreads on bootstrapping:
V [libjvm.so+0x687142] InterpreterRuntime::resolve_invoke(JavaThread*, Bytecodes::Code)+0x1b2
j org.elasticsearch.bootstrap.JNANatives.trySetMaxNumberOfThreads()V+20
j org.elasticsearch.bootstrap.Natives.trySetMaxNumberOfThreads()V+17
j org.elasticsearch.bootstrap.Bootstrap.initializeNatives(Ljava/nio/file/Path;ZZZ)V+75
I have checked/updated the ulimits for the current user, but it seems like JNANatives is not allowed to execute this methods. The service starts fine as root, but I want to avoid any root processes on the server. Does someone had a similar problem? How can I debug this? What could be the issue here?
Many thanks
Now, I found the problem and want to share it here, so that anyone has a similar issues finds a possible hint.
I figured out that some folders up the hierarchy, there was a mount involved causing some permission issues. This causes a hotspot JVM native error in org.elasticsearch.bootstrap.JNANatives.trySetMaxNumberOfThreads().
Liferay reports java.io.StreamCorruptedException: invalid type code: 23 for elasticsearch.
I thought it was due to a ulimit, but it wasn't. Fixing mount/folder permissions on a top level folder, resolved the bootstrapping issues.
So I am trying to build an application that uses libtorrent. However, before I start I would like to make sure that I have compiled the lib correctly and that I have a functioning environment for testing.
I am currently running a VM with opentracker and I try to connect using the example client in libtorrent.
First I start by creating a .torrent file using libtorrent (I am currently not sitting in front of a computer with libtorrent available so I might be remembering the exact commands a bit wrong):
maketorrent.exe dummy.txt -t "http://10.XXX.XXX.XXX/announce"
This gives me a .torrent file called a.torrent. Opening the file everything looks ok, the bencoding is correct and the announce address is there.
Next I try to add it to the example client hoping it starts to seed:
client_test.exe a.torrent
Everything starts up OK, but no tracker is found. Then if I press t to show tracker information I see an error (maybe not the exact phrasing):
Alert: {null} unsupported URL protocol
OK, so maybe something is wrong with how I built libtorrent. So I get the Halite client instead since that is also supposed to be build upon libtorret. But there I have the same problem.
So I have a look at the code and found where this error message is generated. The code is checking if I am supplying an address using the HTTP or HTTPS protocol, which I am. So could it be that I am not able to use a bare IP-address or am I doing something wrong?
I found the problem. It was not a problem with the IP address or the torrent itself. Instead it was a problem with caching.
The first time I added the torrent I used http:\XXX.XXX.XXX.XXX instead of http://XXX.XXX.XXX.XXX which didn't work. However whatever change i did to the torrent file after that did not stick. It was always falling back to that original file until I removed the .resume folder.
EDIT - HUGE ERROR ON MY PART
I found another site that had the issue that I knew was not on the same server. Then I realized that the original site with the issue was also on a different server and had not been moved over completely yet. The server in question was actually a Plesk Parallels' server and the issue was caused by a patch applied to the server over the weekend due to a security update. This server did have the file path and I just had to chmod it to 777 instead of 77x for it to work. I apologize for the confusion and thank everyone for trying to help. +'s for all. :)
Original Post
I have a website on a shared hosting server (also mine) that since yesterday started giving me this error:
Warning: session_start() [function.session-start]: open(/var/lib/php/session/sess_678cf69f0f17b87c52136ee0280d23cc, O_RDWR) failed: Permission denied (13) in /var/www/vhosts/domain.net/httpdocs/index.php on line 1
I've checked /usr/lib/php.ini and /usr/local/lib/php.ini to see where it is set and both say it is set to the /tmp directory, which is where it should be set and always has been. The /var/lib/php/session directory never even existed. I did create it and give it 777 permissions but that did not help. Though the bigger issue here is why did it change to begin with. There is no .htaccess file for this site and I cannot find this being set anywhere on the site itself either.
This is the ONLY site on this server with this issue, telling me its something local to the website. I just cannot figure out what. So my question is this: what should I look for to check the session save path settings for an individual site on a shared hosting environment to find out why it suddenly changed for this one client?
FYI, I am running a WHM server.
Thanks
session_save_path(realpath(dirname($_SERVER['DOCUMENT_ROOT']) . '/../tmp'));
You need to add the above code before starting the session.
You don't appear to have write permission to the /var directory on your server. This is a bit weird, but you can work around it. Before the call to session_start() put in a call to session_save_path() and give it the name of a directory writable by the server. More details here
I found another site that had the issue that I knew was not on the same server. Then I realized that the original site with the issue was also on a different server and had not been moved over completely yet. The server in question was actually a Plesk Parallels' server and the issue was caused by a patch applied to the server over the weekend due to a security update. This server did have the file path and I just had to chmod it to 777 instead of 77x for it to work. I apologize for the confusion and thank everyone for trying to help. +'s for all. :)
The site has been just moved to a new host. Everything works as it is supposed, but when trying to log in as administrator, I am given the following error:
Internal Server Error
The server encountered an internal error or misconfiguration and was unable to complete your request.
Please contact the server administrator, webmaster#localhost and inform them of the time the error occurred, and anything you might have done that may have caused the error.
More information about this error may be available in the server error log.
Any idea of what can be wrong? htcaccess file is renamed to htcaccess.txt
If you follow everything in here you will find what you forgot.
Typically configuration.php is what is forgotten. In addition I strongly recommend Akeeba backup. Something to think about next time.
I have finaly figured it out. The htaccess.txt was in the root directory. What I had to do is to rename the .htaccess file in administrtor folder.