.Net Core (3.1) Web API using Docker (Linux container).
I have a Db2 connection via nuget package IBM.Data.DB2.Core-lnx (3.1.0.300).
This Db2 connection works fine when I build and run my Dockerfile independently of VisualStudio 2019.
However, when attempting to debug via VS (fast mode), I run into this exception:
Unable to load shared library 'libdb2.so' or one of its dependencies. In order to help diagnose loading problems, consider setting the LD_DEBUG environment variable: liblibdb2.so: cannot open shared object file: No such file or directory
My guess is this failure to locate resources is because of the way fast mode debugging works with Docker containers. With the app output copied to a mount, my IBM ENV variables aren't able to find the NuGet clidriver folder. These typically look like this:
ENV DB2_CLI_DRIVER_INSTALL_PATH="/app/clidriver" \
LD_LIBRARY_PATH="/app/clidriver/lib" \
LIBPATH="/app/clidriver/lib" \
PATH=$PATH:"/app/clidriver/bin:/app/clidriver/lib:/app/clidriver/adm"
How can I update these to point to the mounted app contents? Assuming that is the problem...
*Note that I am installing package libxml2-dev in the base of my Dockerfile.
If anyone has a successful strategy for debugging Db2 connections in a Linux container, I would love to hear what you've done. Much thanks in advance.
Running a shell on the debugging container allowed me to see the mounted contents and get the clidriver path. Setting this in the Db2 environment variables fixed the issue:
ENV DB2_CLI_DRIVER_INSTALL_PATH="/app/bin/Debug/netcoreapp3.1/clidriver" \
LD_LIBRARY_PATH="/app/bin/Debug/netcoreapp3.1/clidriver/lib" \
LIBPATH="/app/bin/Debug/netcoreapp3.1/clidriver/lib" \
PATH=$PATH:"/app/bin/Debug/netcoreapp3.1/clidriver/bin:/app/bin/Debug/netcoreapp3.1/clidriver/lib:/app/bin/Debug/netcoreapp3.1/clidriver/adm"
I was facing these concerns almost for a week, glad could resolve the issue.
Solution:
LD_LIBRARY_PATH=<app release folder path>/netcoreapp3.1/clidriver/lib
when you include the LD_LIBRARY_PATH variable, the PATH value gets appended to the existing values along with "../root/usr/lib64"
Please note, If you don't include the LD_LIBRARY_PATH the pod will error out.
Related
Environment
I do use CI/CD of gitlab to bundle my application.
I do use node:14-alpine as image and do run yarn to build my app.
After build is finished, I do deploy my app via rsync to the target-server, which run's ubuntu 20.04.
On this server, I do use pm2 to start the app and keep it running.
Issue
If I look into the logs, I do see an error like this:
I've searched a bit, and found that the issue might be caused of musl-dev is missing.
I've installed it at my server, and into the docker-container, but with same result.
BUT, if I do delete the node_modules directory from server, and run yarn install right at the Server, the app run like expected
Question
So why does this issue happens here? Must I have the same distribution & version of linux in my docker-container to fit all dependencies?
Don't use an Alpine image if you're deploying on Ubuntu.
So why does this issue happens here?
The fundamental C standard library implementation is different on the two (Alpine uses musl libc; Ubuntu and more or less all other distros use GNU C Library (glibc)).
Trying to move binaries (such as those that might appear in node_modules for native modules) built against one libc implementation to a system using the other will likely be painful or not work at all (as you noticed).
Must I have the same distribution & version of linux in my docker-container to fit all dependencies?
If none of the dependencies use native code, then you should be able to just move things over without issues, but otherwise it'll be easiest (e.g. considering the versions of other libraries your dependencies may link against) to just use the same version as your target OS – or, if you don't want to think about that, just deploy your application as a Docker container.
Even if the suggestion from #AKX is a good answer, I've played a bit around to figure out how to solve this special case.
Here is my solution:
install musl-dev at the server
link it to /lib
apt-get install musl-dev
ln -s /usr/lib/x86_64-linux-musl/libc.so /lib/libc.musl-x86_64.so.1
In my case it's only this single dependency which cause the trouble. If I got more of this, I will follow AKX's suggestion and choose a debian/ubuntu-like distribution to bundle it.
I'm trying to build the frontend of a web application in a Node.js Docker container. As I'm on a Windows PC, I'm very limited in my base Images. I chose this one, as it's the only one on DockerHub with a decent number of downloads. As the application is meant to run in Azure, I'm also limited to Windowsservercore 2016. When I run the following Dockerfile, I get the error message below (on my host system the build runs fine btw):
FROM stefanscherer/node-windows:10.15.3-windowsservercore-2016
WORKDIR /app
RUN npm install -g #angular/cli#6.2.4
COPY . ./
RUN ng build
#
# Fatal error in , line 0
# API fatal error handler returned after process out of memory on the background thread
#
#
#
#FailureMessage Object: 000000E37E3FA6D0
I tried increasing the memory available to the build process with --max_old_space up to 16GB (the entire RAM of my laptop) but that didn't help. I also contacted the author of the base image to find out if that's the issue but as this doesn't seem to be reproducable with a smaller example application, that wasn't very fruitful either. I'm working on this issue for a week now and I'm seriously out of ideas what could be the reason. So I hope to get a new impulse from here. At least a dircetion I could investigate in.
What I also tried was getting Node.js and Angular installed on a Windowsservercore base image. If someone has an idea how to do that, it could be the solution.
EDIT: I noticed that the error message is the only output I get from the build process, it doesn't even get to try building the modules. Maybe that means something...
Alright, I figured it out. Although the official Docker documentation states, that Docker has unlimited access to resources, it seems that you need to use the -m option when your build process exceeds a certain amount of memory.
Edit: This question seems to be getting some views so maybe I should clarify this answer a bit. The root of the problem seems to be that under Windows, Docker runs inside a Hyper-V VM. So when the documentation talks about "unlimited access to resources", it doesn't mean your PC's resources, but instead the resources of that VM.
I am new to InfluxDB. I could not find any details about installing InfluxDB on Windows. Is there any way to install it on a Windows machine or do I need to use a Linux server for development purposes?
The current 0.9 branch of influxdb is pure go and can be compiled on Windows with the following commands:
cd %GOPATH%/src/github.com/influxdb
go get -u -f ./...
go build ./...
Of course you will need go (>1.4), git and hg.
If you do not want to compile your own version, you can also find here my own Windows x86 binaries for v0.9.0-rc11:
https://github.com/adriencarbonne/influxdb/releases/download/v0.9.0-rc11/influxdb_v0.9.0-rc11.zip
To run InfluxDB, type: influxd.exe.
Or even better, create the following config file, save it as influxdb.conf and run influxd --config influxdb.conf:
reporting-disabled = true
#[logging]
#level = "debug"
#file = "influxdb.log"
[admin]
enabled = true
port = 8083
[api]
port = 8086
[data]
dir = "data"
[broker]
dir = "broker"
I struggled quite a lot with this issue, so I'll post the full process step by step. This will hopefully help other people that lands on this post.
Table of contents:
Edit: WARNING, this doesn't work if Go and projects folder are installed to a custom path (not c:\go). In this case go get breaks with cryptic messages about unrecognized import paths (thanks to user626528 for the info)
PREVIOUS DOWNLOADS
COMPILATION
EXECUTION
1. PREVIOUS DOWNLOADS
Go for Windows (get the .msi):
https://golang.org/dl/
GIT for Windows:
http://git-scm.com/download/win
2. COMPILATION
cd to C:\Go
Create our $GOPATH in "C:\Go\projects" (anywhere but C:\Go\src, which is the $GOROOT).
> mkdir projects
Set to $GOPATH variable to this new directory:
> set GOPATH=C:\Go\projects
Pull the influxdb code from github into our $GOPATH:
> go get github.com/influxdata/influxdb
cd to C:\Go\projects\github.com\influxdata\influxdb
Pull the project dependencies:
> go get -u -f ./...
Finally, build the code:
> go build ./...
...this will create 3 executables under C:\Go\projects\bin:
influx.exe
influxd.exe
urlgen.exe
3. EXECUTION
To start the service:
influxd -config influxdb.conf
For that, you first need to create a influxdb.conf file with the following text:
reporting-disabled = true
#[logging]
#level = "debug"
#file = "influxdb.log"
#write-tracing = false
[admin]
enabled = true
port = 8083
[api]
port = 8086
[data]
dir = "data"
[broker]
dir = "broker"
Once the service is started, you can execute Chrome and go to http://localhost:8083, and start playing with InfluxDb.
Default values for username and password are:
username: root
password: root
Few updates to Xavier Peña solution to build latest influxdb. Notice the difference in github URL and the path.
C:\Go\projects>go get github.com/influxdata/influxdb
C:\Go\projects>go get github.com/sparrc/gdm
C:\Go\projects>cd C:\Go\projects\src\github.com\influxdata\influxdb
C:\Go\projects\src\github.com\influxdata\influxdb>go get -u -f ./...
C:\Go\projects\src\github.com\influxdata\influxdb>c:\Go\projects\bin\gdm.exe restore
C:\Go\projects\src\github.com\influxdata\influxdb>go build ./...
C:\Go\projects\src\github.com\influxdata\influxdb>go install ./...
C:\Go\projects\bin>influxd config > influxdb.generated.conf
C:\Go\projects\bin>influxd -config influxdb.generated.conf
Windows if officially supported. Go to https://portal.influxdata.com/downloads and download it from there.
The current 0.9 branch of influxdb is pure go and can be compiled on Windows. The main prerequisites are go 1.4, git (e.g. tortoisegit together with msysgit), hg (e.g. tortoisehg).
Using this setup I've successfully compiled and run influxdb on Win7 x64.
There wasn't an influxdb Windows version at Sep 30 '14, there were are only Linux and OSX versions.
Update: Current 0.9 version at present 04/09/2015 have a win version.
The "nightlies" build actually has windows executables now. The release version does not (there is an open issue for that).
Alternatively, downloading the released version and adding the .exe extension to the file names should work as well. You would have to generate the config file using the command:
influxd config >influxdb.conf
Update 2020 - InfluxDB is NOT recommended on windows
After going through countless of articles, it is generally NOT recommended to install InfluxDB directly on Windows. There are many issues. In terms of performance and stability. Official InfluxDB too does not support windows and has no plans for it in the future. This is further proven as the latest InfluxDB 2.0 does not include any windows binaries.
InfluxDB 2.0 does not include windows binaries
so?
Work Around? => DOCKERS for WINDOWS, Try it, it's easy and free
Dockers are free. If you intend to install docker on Windows Server, it's also free for Windows Server 2016 and above (Microsoft made a special deal with docker to provide them for free)
For those who are still in the VM world:
Dockers are NOT like Virtual Machines. It interacts directly with the host's file system via a windows service
Check the link below for a step by step guide:
https://www.open-plant.com/knowledge-base/how-to-install-influxdb-docker-for-windows-10/
We don't officially support Windows at this time. However, you should now be able to build from master. See this issue to track it closely and the comments at the bottom have a link to where you can get a compiled binary:
https://github.com/influxdata/influxdb/issues/5359
For create influxdb configuration file we can also use the below command
influxd config > influxdb.generated.conf
If you don't want to compile it yourself, the build is done by influxdata and can be found at URLs like : https://dl.influxdata.com/influxdb/releases/influxdb-1.0.0-beta2_windows_amd64.zip (just change the version number to have another (recent) version)
However, as mentionned by Paul Dix, Windows is not officially supported for the moment.
Go to influxdata.com click downloads
https://portal.influxdata.com/downloads/
Select version 1.7 because currently there are no binaries for 2.0.
Download Windows binary
I'm new to Sonar, and i was trying to install Sonar 2.8 on my server (Linux 64 on HP-UX)
When i tried to launch it (sonar.sh start) i got the following message
[myHomeDirectory]/sonar/2.8/bin/linux-x86-64/./wrapper: Execute permission denied.
what drives me crazy is that i've putthe whole package on 777 permissions, so i really don't understand what's exactly happening.
Can anyone help with this please ?
Thanks in advance !
I hit a similar issue hence why I came to this post. I was attempting to install SonarQube's scanner in a Docker container but when I was running it, I was getting something along the lines of:
/root/sonar-scanner-2.6.1/bin//sonar-scanner: 103: exec: : Permission denied
I had given the whole /root/ folder all permissions so I was curious about the permission denied. In the end for me it wasn't anything to do with permissions. I simply needed to RTFM.
Sonar-scanner needs a JRE to run and my Docker container didn't have one installed. So if anyone else does the same thing as me, I hope this saves you a few minutes of head scratching.
Not really convinced in the way you are launching it. To get Sonar running I recommend running it on tomcat, providing you just want to use the default database that comes with Sonar. The steps would be:
Install Tomcat
Navigate to your /war directory within your sonar instance and run the command: $] ./build-war.sh.
When this finishes you should see a sonar.war file in the same directory.
Rename the war file ROOT.war instead of sonar.war: $] mv sonar.war ROOT.war
This ensures that sonar runs on tomcat's default port.
Move the war file into the tomcat webapps directory: $] mv ROOT.war /tomcathome/webapps
Navigate to the tomcat /bin folder and run the command $] ./catalina.sh start
Type your server hostname in your browser with a port :8080 at the end and you should see sonar running.
These steps will have sonar running on the default database, though. If you want a MySQL database i'd look at sonar tutorials on how to do that.
I finally came out with the conclusion that the binary file (wrapper) is simply not compiled to run under HP-UX
when launching a file command on wrapper under a Linux i get : <ELF-64 executable object file> which doesn't match the <ELF-64 executable object file - IA64> required by HP-UX running on a Itanium processor
Please check if you have java installed on the machine. Java should be installed on the machine before running sonar-runner.
Use this to check java : java -version
I have followed these instructions.
And as far as I can tell I have successfully installed node.js azure tools. No error - nothing to suggest it failed.
However, I cannot, and the documentation says, simple run "azure"...
Maybe there is something I am missing with node.js?
There are a few problems you may be experiencing.
First of all, I would ensure you are running Node.js v0.6.20. You can do this by opening the command prompt and running:
node -v
You should have v0.6.20 echoed back.
If this doesn't work, you may be missing a path variable to Node.js or the NPM cache. Verify the Environment variables exist by running [in the command prompt]:
path
you should see two paths:
%appdata%\npm
[x64 Machine]
%programfiles(x86)%\nodejs\
[x86 Machine]
%programfiles%\nodejs\
If this doesn't work, I would check to ensure that the azure module was loaded into the %appdata%\npm\node_modules directory.
It could be the PATH issue. In my case, the azure program is located at ~/.npm-global/bin.
run "export PATH=$PATH:~/.npm-global/bin". Or just add to bash source file