I implemented a new server in minix. It seems to work fine, after "service up..." it is up and waits for messages. In client file:
1)I get endpoint with minix_rs_lookup("serverName",*pt)
2)call _syscall(pt,...)
After that I'm getting:
sys_call: ipc mask denied SENDREC from number1 to number2
I searched through minix code and it seems that my process "may not" call this service.
Could anyone explain me why does it happens so?
The problem was with configuration file. I didn't give enough permissions there.
Related
I have had a MineOS setup using the pre-packaged Turnkey bundle on a dedicated system and it worked at first, but recently the system kicked everyone off the server. Any attempt to reconnect give the message: "Authentication servers are down, try again later." and 4 days later, same issue.
From what I can tell this means that the server can't verify my user ID with Mojang's servers for some reason. I checked and there are no disruptions on Mojang's servers, so it must be my system. I tried disabling online-mode and it said "You are not whitelisted on this server." and still wouldn't let any one in. Im thinking this is an error in the firewall configuration but I dont know how or where to start with that. I have already verified that my router is not blocking access to Mojang's servers so it must be within my system configurations somewhere.
What confuses me is why it worked at first and then quit seemingly at random. Any thoughts on what is causing this and how to fix it? thanks in advance for any assistance
turns out the dns server had gotten messed up when changing a static ip. fixed that and everything started working again.
I can't figure this one out. I can't connect to a server using MySQL Workbench, I tried any kind of connection methods. The error message I get is
Failed to Connect to MySQL at AT 127.0.0.1:3306 with user root
Invalid for this platform protocol requested(MYSQL_PROTOCOL_SOCKET)
I ran into the same problem, in my case I originally created the connection with the "Local Socket/Pipe" option selected in the "Connection Method" drop down. Trying to switch back to "Standard (TCP/IP)" did not work and caused the error mentioned by OP. I had to delete the connection and start over by selection "Standard (TCP/IP)" from the start. The connection was successful after that.
To solve this problem you must check the "Others" field in Advanced tab
If you had the connection stored with a socket option you will find a "socket=." (or anything similar)
Delete it
e.g. http://prntscr.com/k63pua
This is a very unusal error message which I haven't seen before, especially on Windows. It has probably to do with how the server is installed. As a newbie it would definitely be the best choice to use the Windows Installer for all required parts. This will install the server properly too.
By using xampp you are on your own to check whether a server is installed and running as a service, as well as the proper configuration. For troubleshooting watch my video on Youtube where I tried to explain most common pitfalls for beginners.
Note: you can open the connection without actually being connected. In that case MySQL Workbench allows to do all those things that don't require a valid server connection, e.g. log file viewing, config file editing, service start/stop etc. Use this to check your server's configuration. Make sure it accepts TCP/IP connections (there's also a short section in the video about this).
Update:
Downvoter, please add a comment why you think my answer is bad.
Re-reading the error message I got another idea: could it be that you used local socket/named pipe for the connection? If so try with normal TCP/IP.
I installed the latest quickfix on a virtual machine environment, it does not work properly. Here is what I found:
1. At server side I run run_executor_python.sh
2. At client side I run run_tradeclient.sh
Server side does not receive anything - I know this because if it does, it prints out the received message.
I modified cfg/tradeclient.cfg and set the SocketConnectHost to 127.0.0.1 and start server at the same VM, this time I can see the server receives messages. So this means my installation is good.
I am wondering if there is some command option I can set so that clientside can print out some status or error message which can help me trace where the problem is. I tried run "./tradeclient -h", but "-h" is not a valid option.
My colleague did the same setup as I did and it worked for me, the only difference is his is on real machines, instead of virtual machines. Do you know if there is known problem on VM? Google does not return anything.
Anyway, thanks a lot.
I'm trying to get the list of available queues on the remote machine. The machine is a Win2003R2 in Workgroup mode, and the client machine that runs the code is a Windows 8 machine both using the same Workgroup name. I get an exception when running the following code:
var messages = MessageQueue.GetPrivateQueuesByMachine("Win2003SRV");
And the error message is:
base {System.Runtime.InteropServices.ExternalException}: {"Access to Message Queuing system is denied."}
Message: "Access to Message Queuing system is denied."
MessageQueueErrorCode: AccessDenied
I'm pretty sure it has something to do with permissions on Windows 2003 but couldn't find much. The code works fine with another Win Server 2008 (but in workgroup mode) and works with local MSMQ as well. According to the MSDN page, this function is supported on Workgroup mode, so what's the catch?
SOLVED:
My issue turned out to be that I didn't have MSMQ installed on my Client machine! The help on the link pointed me to the right direction, so all I had to do was to install MSMQ on client machine as well. If you look at the implementation of GetPrivateQueuesByMachine, the native call can throw a DllNotFoundException and it is that exception that translates into that specific message, so it should give you a hint on what is wrong
John Breakwell who is/was a msmq MVP has a few posts which may help. The problem seems to be caused because the GetPrivateQueuesByMachine() method uses RPC under the hood to communicate between queue managers on different machines.
http://blogs.msdn.com/b/johnbreakwell/archive/2010/03/24/understanding-how-msmq-security-blocks-rpc-traffic.aspx
I have an agent and a server in different domains. The server acts as an MSMQ server and the agent acts as an MSMQ client. I am using the mqsender utility, which is part of the MSMQ tools.
My problem is that a message is not delivered when using the HTTP:// format string (the MSMQ is installed with HTTP support). Using the OS: format string works fine.
When using HTTP the messages are immediately moved to the Dead Letter queue and the Class is set to Unknown, so I do not know the reasons for this behaviour.
So, this works:
mqsender.exe /c:10 /j:dead /f:Direct=OS:il-mark-w2k3\private$\test
And this does not:
mqsender.exe /c:10 /j:dead /f:Direct=http://il-mark-w2k3/msmq/private$/test
I checked that MSMQ virtual directory exists. How can I trace the MSMQ operation to try and understand what is going on?
Thanks.
EDIT
All the commands work as expected when ran locally on the server.
Navigating to http://il-mark-w2k3/msmq/private$/test in the browser on the agent (and the server) results in 501 - Header values specify a method that is not implemented. The same error is received when navigating to http://il-mark-w2k3/msmq. I suppose that is OK, after all it is not 404 - Not Found, right?
EDIT2
I have succeeded to resolve the issue. IIS lacked Anonymous Authentication, it became obvious from observing its log - 401.2 HTTP error was there. All worked well after it was enabled. The mistery remains why did MSMQ display Class Unknown on the dead messages? On other machine the same setup produces Error : 401, which makes much more sense.
The logging for MSMQ is internal so you won't easily be able to see exactly why the message didn't get delivered without raising a support case with Microsoft.
I have a few blog posts on solving various MSMQ/HTTP issues.
The 17 entitled "MSMQ messages using HTTP just won't get delivered" may help.
Also make sure you check the IIS logs for information.
Cheers
John Breakwell