I installed Rmpi on my linux machine and it successfully loads in R. There are two versions of MPICH on my machine, and I (believe) have installed Rmpi with the latest version. I also had to update my LD_LIBRARY_PATH. I primarily followed the installation instructions here.
After loading Rmpi in R, I run mpi.spawn.Rslaves(nslaves=4) and get the following error message:
Error in mpi.spawn.Rslaves(nslaves = 2) :
You cannot use MPI_Comm_spawn API
Does anyone know how I can get Rmpi working?
Thanks!
You need to use MPICH2 for spawn support. If you have MPICH2 installed, you may still need to specify --with-Rmpi-type=MPICH2 when installing Rmpi. If you used --with-Rmpi-type=MPICH instead, it would disable functions such as mpi.spawn.Rslaves.
Also note that MPICH2 apparently does not support spawning workers unless the program is launched using a command such as mpiexec. This basically means that you can't execute mpi.spawn.Rslaves from an interactive R session using MPICH2, although this is possible using Open MPI. To be clear, this is not the issue that you're reporting, but you may encounter this after you have correctly installed Rmpi using MPICH2.
I was able to install Rmpi 0.6-5 using MPICH 3.1.3 with the command:
$ R CMD INSTALL Rmpi_0.6-5.tar.gz --configure-args='--with-mpi=$HOME/mpich-install --with-Rmpi-type=MPICH2'
To debug a configuration problem, you should install Rmpi from a directory rather than a tar file. That will allow you to examine the "config.log" file afterwards which will provide important information. Here is how I did that on my Linux box:
$ tar xzvf Rmpi_0.6-5.tar.gz
$ R CMD INSTALL Rmpi --configure-args='--with-mpi=$HOME/mpich-install --with-Rmpi-type=MPICH2'
In order to get spawn support, the MPI2 macro needs to be defined when compiling the C code in Rmpi. You can check if that is happening by searching for "PKG_CPPFLAGS" in config.log:
$ grep PKG_CPPFLAGS Rmpi/config.log
PKG_CPPFLAGS='-I/home/steve/mpich-install/include -DMPI2 -DMPICH2'
I have found "config.log" to be very useful for debugging configuration and build problems.
Note that you can use Rmpi without spawn support. You'll need to start all of the workers using mpirun (or mpiexec, etc) and it will be much more difficult, if not impossible, to use functions such as mpi.apply, mpi.applyLB, etc. But if you just need to initialize MPI so you can use MPI from functions implemented in C or Fortran, you will probably need to start all of the workers via mpirun.
Related
I'm learning F#, never having used any DotNet nor Mono before. I like the language, but I'm having a hard time with the myriad runtime versions and how to tell the various tools which version to use.
Summary: it appears DLL Hell on Ubuntu is a thing. How can I tell FSAC to run its auto-complete magic against the latest runtime version, namely Microsoft.NETCore.App 2.1.5, instead of whatever older incarnation it decided to use?
Longish explanation.
My platform is Ubuntu 18.04 amd64. I have installed the latest DotNet Core, specifically the packages dotnet-sdk-2.1 (version 2.1.403-1) and its dependencies dotnet-host, dotnet-runtime-2.1, etc. (which are all version 2.1.5-1). I also have Mono installed, because many tools apparently rely on it.
When I try to use some features that were recently added to DotNet Core, it feels like I'm uncovering a Pandora Box.
Take this example, which uses the new ProcessStartInfo.ArgumentList:
#r "System.Diagnostics.Process.dll"
open System.Diagnostics
let execute exe args =
let proc = new Process()
proc.StartInfo.FileName <- exe
for arg in args do proc.StartInfo.ArgumentList.Add arg
proc.Start() |> ignore
proc.WaitForExit()
execute "echo" ["foo"; "baz"]
If I naively try to run it with /usr/bin/fsharpi (which exec's /usr/bin/mono /usr/lib/mono/fsharp/fsi.exe) I get a "ArgumentList is not defined" error. Fair enough, I guess?
If I run it with /usr/bin/dotnet /usr/share/dotnet/sdk/2.1.403/FSharp/fsi.exe it works! It took me a long time to figure out I could even do it, but at last I'm on the right path.
But if I load the file in any IDE, such as VSCode with the Ionide plugin, or Sublime Text with the FSharp plugin, they still flag ArgumentList as invalid. Sublime's plugin also flags the #r line as invalid, but doesn't tell me why.
Focusing on Sublime's plugin and digging into the code, it appears that it relies on a tool called FsAutoComplete aka. fsac and on Linux explicitly invokes it with mono.
I tried running the FSAC tool with DotNet Core, but it fails to find some library or other:
$ cd .config/sublime-text-3/Packages/FSharp/fsac/fsac/
$ dotnet fsautocomplete.exe
A fatal error was encountered. The library 'libhostpolicy.so' required to execute the application was not found in '/home/tobia/.config/sublime-text-3/Packages/FSharp/fsac/fsac/'.
Failed to run as a self-contained app. If this should be a framework-dependent app, add the /home/tobia/.config/sublime-text-3/Packages/FSharp/fsac/fsac/fsautocomplete.runtimeconfig.json file specifying the appropriate framework.
If I take a filesystem approach and search for System.Diagnostics.Process.dll, I'm baffled by the results:
/usr/lib/mono/4.5/Facades/System.Diagnostics.Process.dll
/usr/lib/mono/4.7.1-api/Facades/System.Diagnostics.Process.dll
/usr/lib/mono/xbuild/Microsoft/Microsoft.NET.Build.Extensions/net461/lib/System.Diagnostics.Process.dll
/usr/share/dotnet/sdk/2.1.403/Microsoft/Microsoft.NET.Build.Extensions/net461/lib/System.Diagnostics.Process.dll
/usr/share/dotnet/sdk/NuGetFallbackFolder/microsoft.netcore.app/2.1.0/ref/netcoreapp2.1/System.Diagnostics.Process.dll
/usr/share/dotnet/sdk/NuGetFallbackFolder/netstandard.library/2.0.3/build/netstandard2.0/ref/System.Diagnostics.Process.dll
/usr/share/dotnet/sdk/NuGetFallbackFolder/system.diagnostics.process/4.3.0/lib/net46/System.Diagnostics.Process.dll
/usr/share/dotnet/sdk/NuGetFallbackFolder/system.diagnostics.process/4.3.0/lib/net461/System.Diagnostics.Process.dll
/usr/share/dotnet/sdk/NuGetFallbackFolder/system.diagnostics.process/4.3.0/ref/net46/System.Diagnostics.Process.dll
/usr/share/dotnet/sdk/NuGetFallbackFolder/system.diagnostics.process/4.3.0/ref/net461/System.Diagnostics.Process.dll
/usr/share/dotnet/sdk/NuGetFallbackFolder/system.diagnostics.process/4.3.0/ref/netstandard1.3/System.Diagnostics.Process.dll
/usr/share/dotnet/sdk/NuGetFallbackFolder/system.diagnostics.process/4.3.0/ref/netstandard1.4/System.Diagnostics.Process.dll
/usr/share/dotnet/sdk/NuGetFallbackFolder/system.diagnostics.process/4.3.0/runtimes/linux/lib/netstandard1.4/System.Diagnostics.Process.dll
/usr/share/dotnet/sdk/NuGetFallbackFolder/system.diagnostics.process/4.3.0/runtimes/osx/lib/netstandard1.4/System.Diagnostics.Process.dll
/usr/share/dotnet/sdk/NuGetFallbackFolder/system.diagnostics.process/4.3.0/runtimes/win/lib/net46/System.Diagnostics.Process.dll
/usr/share/dotnet/sdk/NuGetFallbackFolder/system.diagnostics.process/4.3.0/runtimes/win/lib/net461/System.Diagnostics.Process.dll
/usr/share/dotnet/sdk/NuGetFallbackFolder/system.diagnostics.process/4.3.0/runtimes/win/lib/netstandard1.4/System.Diagnostics.Process.dll
/usr/share/dotnet/shared/Microsoft.NETCore.App/2.1.5/System.Diagnostics.Process.dll
Plus another dozen in my home directory, under ~/.nuget. That's insane.
To begin with, the entire /usr/share/dotnet/sdk/NuGetFallbackFolder subtree does not seem to be owned by any Deb package, which is worrisome enough. The others belong to these packages:
mono-devel: /usr/lib/mono/4.5/Facades/System.Diagnostics.Process.dll
mono-devel: /usr/lib/mono/4.7.1-api/Facades/System.Diagnostics.Process.dll
msbuild: /usr/lib/mono/xbuild/Microsoft/Microsoft.NET.Build.Extensions/net461/lib/System.Diagnostics.Process.dll
dotnet-sdk-2.1: /usr/share/dotnet/sdk/2.1.403/Microsoft/Microsoft.NET.Build.Extensions/net461/lib/System.Diagnostics.Process.dll
(*) dotnet-runtime-2.1: /usr/share/dotnet/shared/Microsoft.NETCore.App/2.1.5/System.Diagnostics.Process.dll
Running a simple Grep shows that only the last one marked with (*) knows anything about ArgumentList.
So all these other libraries are older / legacy versions, including the one in dotnet-sdk-2.1 itself.
I can only presume that the SDK, aka. the compilers and interpreters, are built against an older version of the runtime / system libraries than the one they build code against. Which is an interesting choice, to say the least.
Taking a process approach, lsof tells me that the FSAC process has only opened DLL files from inside /usr/lib/mono and from its own local directory. This is not promising.
Is there a way to tell FSAC to use the Microsoft.NETCore.App 2.1.5 runtime / system libraries for its autocomplete and linting work?
Often I need to install supporting libraries on Linux to get my (or third party) app working. The process usually involves running configure and apt/yum install multiple times. Is this possible after the installation is over and the app was successfully compiled to get the list of all packages that were installed during the process by yum/apt? Or just yum or just apt if only some of them supports this.
Right now I have to use history | grep apt but this usually causes many invalid attempts to be included int he output.
As much I know that mcelog is used to check the memory errors in the hardware. I want to simulate the same case. I don't have any machine which is having the issue with hardware where I can simulate this case. Can anybody suggest me some simulator or any other way through which I can generate these errors. Because my main aim is to display the Uncorrectable Memory errors. Thanks.
You can use the tool mce-inject, but you'll need to load the mce_inject kernel module. This kernel module is available on Ubuntu 12.04 (the only system I have access to) and should be available on newer Ubuntus, as well.
First, you need to load the module:
$ sudo modprobe mce_inject
Next, you need to download the source for the mce_inject tool, install the dependencies, and compile it:
$ git clone https://github.com/andikleen/mce-inject.git
$ sudo apt-get install flex bison
$ cd mce-inject
$ make
Next, you need to create a file that simulates the error you want. You should check the mce-inject man page (included in the source) for more information on the structure. You can find some examples in the test/ directory in the [mce-inject source](
Injecting a FATAL error can destabilize and crash the system; doing this is not recommended.
Once you've decided which example file to use (or have created your own) you can inject it with mce-inject. For example, injecting the test/corrected example error included with mce-inject:
$ sudo ./mce-inject test/corrected
You can now check your logs and find that the error has been injected.
I’ve written a very small application in Go, and configured an AWS Linux AMI to host. The application is a very simple web server. I’ve installed Go on the Linux VM by following the instructions in the official documentation to the letter. My application runs as expected when invoked with the “go run main.go” command.
However, I receive an “Invalid argument” error when I attempt to manually launch the binary file generated as a result of running “go install”. Instead, if I run “go build” (which I understand to be essentially the same thing, with a few exceptions) and then invoke the resulting binary, the application launches as expected.
I’m invoking the file from within the $GOPATH/bin/ folder as follows:
./myapp
I’ve also added $GOPATH/bin to the $PATH variable.
I have also moved the binary from $GOPATH/bin/ to the src folder, and successfully run it from there.
The Linux instance is a 64-bit instance, and I have installed the corresponding Go 64-bit installation.
go build builds everything (that is, all dependent packages), then produces the resulting executable files and then discards the intermediate results (see this for an alternative take; also consider carefully reading outputs of go help build and go help install).
go install, on the contrary, uses precompiled versions of the dependent packages, if it finds them; otherwise it builds them as well, and installs under $PATH/pkg. Hence I might suggest that go install sees some outdated packages which screw the resulting build.
Consider running go install ./... in your $GOPATH/src.
Or may be just selective go install uri/of/the/package for each dependent package, and then retry building the executable.
All,
My host supports Perl CGI scripts, how do I use a compiled CGI script on the host?
I tried setting execute permissions via chmod, but when I try and run it via the browser, I get a server error.
Thanks in advance for all help.
It's possible with a few restrictions:
You're compiling statically or don't have any external dependencies
You're using a glibc that's no newer than theirs
If you're compiling under gcc, you might also need to provide libgcc_s.so which might mean you need a LD_LIBRARY_PATH in which case you'd probably run your binary through a shell script.
You can check the dependencies on your binary with ldd. My recommendation is to compile statically with no dependencies on a system with a glibc at least as old as theirs.
NOTE: (1) above isn't strictly a requirement if you can set LD_LIBRARY_PATH and can run everything through a wrapper script, but things get much more complicated if you need such functionality.
perhaps i'm missing something, but the fact that your host supports "perl cgi" doesn't mean that they support "compiled cgi" (which i would presume is a C CGI program).
Some details about what the server error was would be helpful.