I've written a code that utilizes OpenMPI for a message passing interface. However, when I run the code, it freezes everything on my computer except for my mouse and the only fix is a forced restart or a shut down.
I'm running the code from WSL and when I don't have my antivirus (Symantec Endpoint Protection) on, it will run just fine. The issue is, I need SEP to get onto the VPN I need for work.
I've tried running WSL as an admin and I'd try using other antivirus but SEP is the one I need for the VPN. Is this a common issue with MPI? Is there a way I can work around this without having to disable my firewall everytime I want to run the code?
I apologize if this is to vague and will gladly post any other information that may be useful. I'm just not sure what may be useful for right now.
Related
Xterm is used when running Corda locally on one computer using gradle.
Is there a way to specify your terminal editor when running as suggested by the following issue?
https://github.com/corda/corda/issues/2605
I completely share your pain on this. The way that runnodes has its tooling baked in makes it impossible for you to customize how the cordform plugin runs the nodes without digging into the internals.
Some other ideas for you
one thing you could do would be to stop using cordform altogether and run your corda network using dockerform (example here: https://github.com/corda/samples-java/blob/master/Features/dockerform-yocordapp/build.gradle#L93) so that the plugin doesn't need to actually create new terminals.
the much harder way would be to actually download the corda gradle plugins (https://github.com/corda/corda-gradle-plugins#installing-locally) and install it locally with your edits to the cordform task so that it opens the terminal of your choice. You may be able to PR them as the cordform task that's usually used to generate the runnodes script comes from here as far as I know.
As a separate note, I saw your github issue and I was disappointed by how that got handled. I'm sorry you had that experience and I'm going to dig into that issue internally to find out what's happening with that.
feel free to reach out to me (David Awad) on slack.corda.net and I can let you know what's going on there.
Thanks as always
TCP connections work fine as I am able to converse with someone over zoom and teamviewer. However, whenever I attempt to access another webpage, I get a network error. Google seems to work fine for some reason but any webpage I go to listed by Google fails to connect. The only way I can open up my http connections is by ending a task called "init" inside of task manager. This shuts down my vscode as well as my ubuntu terminals I have running. If someone knows the solution please do tell. It's really annoying having to close out my vscode and terminals as well as my local servers to look up information and debug.
I found a fix to this issue.
So I was running a Windows Subsystem for Linux and my Windows Build was outdated as well as WSL. When I updated Windows and upgraded to WSL2, my issue was resolved and I don't seem to get any more network errors.
I have R Studio on Windows. It works fine before I connect to the internet through my VPN. After I connect commands start to hang, autocomplete can take forever, and simple operations like 4 + 4 can take one minute or more.
I have a feeling the studio is making connections under the hood. I would like to disable all of these connections no matter what.
I have experienced the same thing - I am assuming your actual work is on a file server and not local. I found the culprit in my case to not be RStudio directly, but rather the RStudio project file. RStudio will create a generally small, hidden folder in the directory named .Rproj.user with some settings. This, living on the file server, caused constant read/writes through my VPN connection.
I unfortunately had to either (a) move projects off the file server into a local copy (not bad since I can use a company GitLab), or (b) delete the .Rproj and .Rproj.user folders from the project directory on the server and use here::here() or something like that as a work around in my workflow.
As another possibility, I have seen installations of R itself done onto a personal server drive instead of locally. This has been done to avoid needing administrator privileges to install. This is not a great idea and can also result in extremely slow performance through a VPN connection. You can check to see where R is installed as well. Sounds like this is not the problem though based on what you described.
Maybe it is something else, but this is what I found last week for me based on a very similar experience.
I currently have a Plone 4.3.8 site where editing a portlet causes a deadlock.
I'm trying to find tools to fix this, but most deadlock tools don't work & I'm not getting good information (IMO) from those that at least run.
I've tried:
z3c.deadlockdebugger => can't get to a stacktrace
ZopeHealthWatcher => can't see the results on command line (or webpage)
Products.LongRequestLogger => perhaps the best so far, gives me some log output - but it's stack traces focus on Diazo code, but the problem still occurs when Diazo isn't in scope (running against 127.0.0.1)
gdb attach - just landed me in C code
winpdb => it can't attach to running processes in the same way that gdb can (only to processes started with the intention of attachment by winpdb)
Products.signalstack (OR Products.signalstacklogger) => USR1 signal just shuts down a zope process!
Note: z3c.deadlockdebugger (and things that depend on it) needs checked out source code to drop the threadframe dependency.
My situation seems to be linked to product upgrades - probably one or both of either plone.app.contenttypes or plone.app.multilingual, an empty site doesn't have this issue, but I obviously I need my site data!
What should I do to progress this?
EDIT:
I believe Maurits answer to be the most correct one, but it didn't work in my case. What I ended up doing was using pdb to track down the point at which the code was hanging (in plone.app.debugtoolbar as it happens)
You say that using the USR1 signal shuts down Zope when using Products.signalstack. But no special packages should be necessary, so I wonder if adding signalstack has this side effect of shutting down Zope.
At least for me, a few weeks ago, this worked fine on a Plone 4.3.something site:
kill -USR1 $(cat var/zeoclient.pid)
Although the #maurits answer is right (and the simplest ones) sometimes I had issues seeing the traceback resulting from the kill command: sometimes is found on the event log, sometimes on the shell.
I prefer the integration of the buildout with haufe.requestmonitoring, configuring also the monitor long running requests feature.
You will see the deadlocked traceback in your event log and also you activate a tool for monitoring low performance on your Plone.
I've run into an issue with Saltstack version 2014.7.0, where I cannot get network information from Salt.
If I run:
salt-call network.ip_addrs
I get:
Function network.ip_addrs is not available
This only seems to happen on some of my hosts. It seems to effect the almost all of the functions in salt.modules.network, but everything else works as expected.
I suspect there's something in my environment to blame. I am running salt within a CentOS 7 docker container. I followed these instructions to get Systemd running under Docker, and it seems to be functioning just fine, so I don't think that's the issue, but I wouldn't be surprised if it's related. I'm using Docker as a development environment, but I will be using these formula to orchestrate virtual machines in production.
Has anyone encountered the network module not being loaded properly? Is there something that needs to be available for that module to be accessible?
I have other mechanisms to get the IP address, but none that are as easy to work with in other salt formulas.
It turns out my problem was that I had my own custom module called "network" which was obscuring the upstream network module.
I'm pretty sure this was working at some point in the past, so I'm wondering if there might have been a change to salt in a more recent version that would cause it to conflict at a module level instead of merging methods from different modules of the same name, but I suppose it's possible that it never worked.