I am running an Ubuntu server with 8 cores. However imagemagick always only uses 1 single core.
Running identify -version returns:
Version: ImageMagick 6.6.9-7 2012-08-17 Q16 http://www.imagemagick.org
Copyright: Copyright (C) 1999-2011 ImageMagick Studio LLC
Features: OpenMP
So OpenMP which is apparently needed for multi threading is enabled.
Running a benchmark with -bench option (e.g. convert logo: -resize 500% -bench 10 logo.png) as described here returns
Performance: 10i 1.17647ips 14.390u 0.14166666666833332977:08.500
It does not return Performance[1] through Performance[8] as described in the manual which makes me wonder.
Any ideas how I can get imagemagick to use all 8 cores?
Update: Here is the strace output from an imagemagick call: http://pastebin.com/Q0gC3k09
I was able to reproduce this behavior on Ubuntu 10.04. ImageMagick from apt-get seems to have the OpenMP feature, and configure with the -fopenmp flag, but the feature doesn't seem to be enabled. This can be verified by running the following line, and comparing the "FEATURES" list (if present) to the various configuration flags.
identify -list Configure | less
I was able to resolve this by following the article "Installing ImageMagick from Source on Ubuntu 8.04" which detailed the following process.
Remove ImageMagick
Install all the needed image/graphic dependency libraries through apt-get
Download
wget http://www.imagemagick.org/download/ImageMagick-6.8.6-6.tar.gz
Follow basic ./configure, make, & sudo make install steps
Export library path to /usr/local/lib
This seems to work as OpenMP is now present under "FEATURES" list, and when I execute convert logo: -resize 500% -bench 10 logo.png. I see the following
Performance[1]: 10i 0.750ips 1.000e 18.750u 0:13.330
Performance[2]: 10i 0.751ips 0.500e 18.660u 0:13.320
Performance[3]: 10i 0.738ips 0.496e 18.840u 0:13.550
Performance[4]: 10i 0.469ips 0.385e 19.560u 0:21.320
And these results match what I would expect.
Some tests I made on my side but I not able to setup a real or virtualized multicore machine to reproduce. So I don't come with a real solution but more with a strategy to investigate because it really seems to be system dependent.
But at least I can say that:
if you get the last ImageMagick source from http://www.imagemagick.org/script/install-source.php#unix, you should be able to rebuild IM for your system.
if you want to be sure that your compiler handle the code as expected, you can do the following before calling "make", Edit the magick/studio.h file, found the line 143, you should see the following.
#if defined(_OPENMP) && ((_OPENMP >= 200203) || defined(__OPENCC__))
# include <omp.h>
# define MAGICKCORE_OPENMP_SUPPORT 1
#endif
Modify those line to add a compiler diagnostic message:
#if defined(_OPENMP) && ((_OPENMP >= 200203) || defined(__OPENCC__))
# include <omp.h>
# define MAGICKCORE_OPENMP_SUPPORT 1
# pragma message "MAGICKCORE_OPENMP_SUPPORT 1"
#endif
Now run the './configure' and after the 'make' command, you should see the message you added every time studio.h is used and BTW MAGICKCORE_OPEN_SUPPORT macro set to 1.
MAGICKCORE_OPENMP_SUPPORT is the macro that IM use internally to enable/disable the preprocessing of the OpenMp directives, so if you see the message, all #pragma omp of the code will be process for real.
If everything is ok until now try to perform the 'make install' command and check if your 'bench' command work better (multicore) with your own version of convert (/usr/local/bin/convert)
if it's still not working, it means that it's not related to IM, but that openMP based program don't run correctly on your system. In that case you should consider the following question Why OpenMP program runs only in one thread, and check openMP support with a shorter program to build and run than IM !
Related
I tried installing imagemagick using homebrew on a Mac. Specifically, I did:
brew install imagemagick
in terminal. There were no error messages. When I go to use imagemagick, e.g. using the command:
magick convert
I don't see the magick command available when I try to tab complete. I'm a bit uncertain how to debug this -- it seems like it should have installed fine?
As part of installing homebrew you need to set your PATH so your shell knows where the executable binaries are installed.
Depending on your homebrew version and macOS hardware and software, you may need:
export PATH=/opt/homebrew/bin:$PATH
or
export PATH=/usr/local/bin:$PATH
You can tell which of the two commands above you need with:
find {/opt/homebrew,/usr/local}/bin -name magick
Then run:
hash -r
and all homebrew commands like magick should work for your current session.
If you want the PATH set correctly for all future sessions you will need to add the export command from above to your login profile. That will depend on your shell, but is probably:
$HOME/.zprofile
or
$HOME/.profile
Note that you should read this answer to understand why you do NOT want to use magick convert.
I have a docker base image when uploaded to quay image repository give the vulnerability pyup.io-43366 (CVE-2021-43818).
The base image is
FROM quay/registry.redhat.io/rhel7:latest
MAINTAINER Me
LABEL description="Application runtime image" \
name="Image name" \
version="1.0"
ENV LANG en_US.UTF-8
RUN yum-config-manager \
&& yum -y install java-11-openjdk \
&& yum -y clean all
CMD ["/bin/bash"]
Is there any way I can overcome this vulnerability?
Red Hat provides this information describing how the issue affects different products versions.
As described in the aforementioned link, it seems that no mitigation is provided:
Mitigation for this issue is either not available or the currently
available options do not meet the Red Hat Product Security criteria
comprising ease of use and deployment, applicability to widespread
installation base or stability.
In the specific use case of Red Hat Enterprise Linux 7, they indicate the product is "Out of support scope":
When a product is listed as "Out of Support Scope", it means a
vulnerability with the impact level assigned to this CVE is no longer
covered by its current support lifecycle phase. The product has
been identified to contain the impacted component, but analysis to
determine whether it is affected or not by this vulnerability was not
performed. The product should be assumed to be affected. Customers are
advised to apply any mitigation options documented on this page, consider
removing or disabling the impacted component, or upgrade to a supported
version of the product that has an update available.
This may explain, as VonC indicated in his question, why Grype doesn't report the problem.
If you need your image just for running Java, one thing you could try is removing the dependency, but I am afraid it is required by other libraries, so probably it will not work.
Please, take my words with caution because it entirely depends on your actual use case, but you may "safely" use your image as well. From the cited docs again:
This flaw is rated as Moderate because code execution is limited to the web
browser scope.
In fact, Red Hat itself provides similar images with the same problem.
Finally, if using Red Hat is not a strict requirement, you can choose another different Java distribution like OpenJDK or AdoptOpenJDK. For example:
docker pull openjdk:11.0.14.1-jdk
"stop using latest" -- "what tag should I give?"
First, you can list tags from rhel7, using the regclient project from Brandon Mitchell (sudo-bmitch, top contributor on Stack Overflow), with:
alias dr='docker run -it --rm'
# on Windows
dockey dr=docker run -it --rm $*
dr regclient/regctl:latest tag ls registry.access.redhat.com/rhel7|\
grep -Ev (source|[0-9][0-9][0-9][0-9])
(on Windows: grep -Ev (source^|[0-9][0-9][0-9][0-9]): note the ^)
Second, I do not see CVE-2021-43818 in latest, using anchore/grype
docker run anchore/grype:latest registry.access.redhat.com/rhel7:latest | grep 2021
The closest is CVE-2021-3541, a flaw was found in libxml2-python.
In your case, considering Lxml 4.6.5 includes a fix for CVE-2021-43818, you would need an image with Lxml 4.6.5+.
If that image does not exist yet, you could docker build your own starting FROM registry.access.redhat.com/rhel7:7.9, and adding the right libxml.
And publish it to Quay.
I've been trying for a few hours now solve this problem and I looked everywhere for a solution and I did not find one. I'm trying to run a spec test for my project and I have the following error coming up:
RuntimeError:
Ghostscript not found in your system environment (linux-gnu).
Install it and set the variable RGhost::Config::GS[:path] with the executable.
Example: RGhost::Config::GS[:path]='/path/to/my/gs' #unix-style
RGhost::Config::GS[:path]="C:\\gs\\bin\\gswin32c.exe" #windows-style
And I do try to put RGhost::Config::GS[:path]='/usr/local/bin/gs' and it returns:
bash: RGhost::Config::GS[:path]=/usr/local/bin/gs: No such file or directory
but ghostscript is installed, I did everything (make, sudo make install, etc etc) and when I run gs -v it returns:
GPL Ghostscript 9.26 (2018-11-20)
Copyright (C) 2018 Artifex Software, Inc. All rights reserved.
When I use the user interface and search for "gs" in the "Files" application, it is found in /home/marcelle/projects/ghostscript-9.26/bin/gs and I also tried:
RGhost::Config::GS[:path]='/home/marcelle/projects/ghostscript-9.26/bin/gs'
and it returns the same error:
bash: RGhost::Config::GS[:path]=/home/marcelle/projects/ghostscript-9.26/bin/gs: No such file or directory
I also tried to delete ghostscript from my notebook with autoremove and purge and installed it again using what I mentioned before (./configure, make, sudo make install), restarted the notebook, the terminal and nothing.
PS: I'm using Ubuntu 20.04.
I managed to figure out a solution. Looking for the code for the Rghost, what I saw in its spec is that the path expected was different than the path the ghostscript really is.
When I run whereis or which on my terminal, it returns:
which gs
/usr/local/bin/gs
So I was trying to point to this path. But seeing the spec test for Rghost which I found on github for Rghost, we can see that it expects /usr/bin/gs:
it 'should detect linux env properly' do
RbConfig::CONFIG.should_receive(:[]).twice.with('host_os').and_return('linux')
File.should_receive(:exists?).with('/usr/bin/gs').and_return(true)
RGhost::Config.config_platform
RGhost::Config::GS[:path].should == '/usr/bin/gs'
end
So it expects /usr/bin and not /usr/local/bin.
Then I just copied to that path and the spec ran with no problems anymore:
sudo cp /usr/local/bin/gs /usr/bin
I've no experience with Ruby at all, but I also got this error when using asciidoctor, which uses rghost for the PDF generation.
The command RGhost::Config::GS[:path]='/path/to/my/gs' mentioned in the error is not a shell command, which is why bash couldn't handle it. However, to me it wasn't immediately clear what to do with this command either. I expected an easy way to set this variable somewhere, but couldn't find it.
What worked for me was searching the rghost.rb file, which is where this variable is set and can be changed. In Windows, it was located in C:\Ruby30-x64\lib\ruby\gems\3.0.0\gems\rghost-0.9.7\lib\rghost.rb.
In this file, I added the following line, which solved the problem:
RGhost::Config::GS[:path]="C:\\Program Files\\gs\\gs9.55.0\\bin\\gswin64c.exe"
NB: the mentioned paths can be different for everyone, so make sure to use that paths that are valid for your system.
I need to build a "slim" docker image which only contains the mono runtime in order to execute a pre-compiled F# app. In other words, I want to create the leanest possible image for executing mono apps, without any of the additional stuff for compiling/building apps. I am using Ubuntu:16.04 as a my base image (which weighs at around 47MB).
If I try to install mono on top of that image (using apt-get install mono-devel), then the image grows to whopping 500MB. This of course happens because the entire mono development tools are installed.
How can I proceed to only create an image containing the mono runtime? Is there a way installing through apt-get the mono runtime?
I'm answering the question as it is stated:
How can I proceed to only create an image containing the mono runtime?
For that, the answer is yes. There is a package for just the runtime called mono-runtime. In addition to that, there is an apt option to ignore installing recommended packages (usually docs and other stuff that may not be necessary for a runtime) with --no-install-recommends. Combining the two, we can get down to around 240 MB on the Ubuntu base:
FROM ubuntu
RUN apt update && apt install -qy --no-install-recommends mono-runtime libfsharp-core4.3-cil
Also mentioned in comments, there are some more minimal images based on Alpine linux that may be of interest such as https://hub.docker.com/r/frolvlad/alpine-mono/ (which at the moment is around 200 MB).
I have installed ImageMagick through apt-get in Ubuntu 12.04. Now I need to enable HDRI support for my ImageMagick scripts. How can I do that?
You should run
convert -list configure | grep FEATURES
If the result does not list HDRI, then you need to get a different build of ImageMagick. Your current one will not support it (it cannot be "added in" by the simple change of a local configuration setting).
Either build it yourself from sources, or ask your Ubuntu package maintainer in the most friendly way you can to provide an alternative build.
It's possibly still disabled in Ubuntu because the ImageMagick developer themselves call it an "experimental feature".