Docker 127 error

We're running into a pretty critical issue with our Docker container setup. Some containers appear to be arbitrarily exiting with 127 exit codes. The 127 exit code doesn't make sense since ...

UPDATE: Despite the error — it does appear to be removing the container now (it wasn’t before).

Getting the same issue here — I hope this detail helps troubleshoot!

> docker rm -f 672c1482bf99
Error response from daemon: Cannot destroy container 672c1482bf99: Driver devicemapper failed to remove root filesystem 672c1482bf99727d9fb2437f6d39c3ab4f702034e4dd11c68d4ef811a559ed3a: Device is Busy

Running on an Amazon CentOS EC2 instance:

> uname -r  
3.4.103-76.114.amzn1.x86_64
> docker version
Client version: 1.2.0
Client API version: 1.14
Go version (client): go1.3.1
Git commit (client): fa7b24f
OS/Arch (client): linux/amd64
Server version: 1.2.0
Server API version: 1.14
Go version (server): go1.3.1
Git commit (server): fa7b24f
> docker info
Containers: 4
Images: 7
Storage Driver: devicemapper
 Pool Name: docker-202:1-280651-pool
 Pool Blocksize: 64 Kb
 Data file: /var/lib/docker/devicemapper/devicemapper/data
 Metadata file: /var/lib/docker/devicemapper/devicemapper/metadata
 Data Space Used: 1555.8 Mb
 Data Space Total: 102400.0 Mb
 Metadata Space Used: 1.8 Mb
 Metadata Space Total: 2048.0 Mb
Execution Driver: native-0.2
Kernel Version: 3.4.103-76.114.amzn1.x86_64
Operating System: <unknown>
Debug mode (server): true
Debug mode (client): false
Fds: 11
Goroutines: 11
EventsListeners: 0
Init Path: /usr/bin/docker
WARNING: No memory limit support
WARNING: No swap limit support

Finally, here’s the logs from /var/log/docker for the docker rm -f:

[debug] server.go:1036 Calling DELETE /containers/{name:.*}
[info] DELETE /v1.14/containers/672c1482bf99?force=1
[b9415f80] +job delete(672c1482bf99)
[debug] deviceset.go:281 activateDeviceIfNeeded(672c1482bf99727d9fb2437f6d39c3ab4f702034e4dd11c68d4ef811a559ed3a)
--- {{ REPEATED ABOUT 100 TIMES }} --
[debug] devmapper.go:545 [devmapper] removeDevice START
[debug] deviceset.go:451 libdevmapper(3): ioctl/libdm-iface.c:1768 (-1) device-mapper: remove ioctl on docker-202:1-280651-672c1482bf99727d9fb2437f6d39c3ab4f702034e4dd11c68d4ef811a559ed3a failed: Device or resource busy
[debug] devmapper.go:554 [devmapper] removeDevice END
--- {{ REPEATED ABOUT 100 TIMES }} --
[debug] deviceset.go:719 Error removing device: Device is Busy
Cannot destroy container 672c1482bf99: Driver devicemapper failed to remove root filesystem 672c1482bf99727d9fb2437f6d39c3ab4f702034e4dd11c68d4ef811a559ed3a: Device is Busy
[b9415f80] -job delete(672c1482bf99) = ERR (1)
[error] server.go:1062 Handler for DELETE /containers/{name:.*} returned error: Cannot destroy container 672c1482bf99: Driver devicemapper failed to remove root filesystem 672c1482bf99727d9fb2437f6d39c3ab4f702034e4dd11c68d4ef811a559ed3a: Device is Busy
[error] server.go:91 HTTP Error: statusCode=500 Cannot destroy container 672c1482bf99: Driver devicemapper failed to remove root filesystem 672c1482bf99727d9fb2437f6d39c3ab4f702034e4dd11c68d4ef811a559ed3a: Device is Busy

«Life is all about sharing. If we are good at something, pass it on.» — Mary Berry

  • About
  • Projects
  • Photos
  • Categories

  • Tags

Why my golang docker container exits immediately (code 127)?

visitor badge

2019-10-30

Categories:

DevOps

To trim the binary size, I used LDFLAGS='-w -s', pack with upx, then build from scratch. The thing is when starting, it exited immediately with code 127. Why?

My Dockerfile:

1FROM scratch
2
3WORKDIR /app
4
5COPY build/linux/<binary> .
6
7ENTRYPOINT [ "/app/<binary>" ]

When starting:

10fbce782a9bd        quantonganh/<binary>:T276-dockerize                              "/app/<binary>"           6 seconds ago       Exited (127) 4 seconds ago                                           relaxed_thompson

and there is no logs at all:

1❯ docker logs 0fbce782a9bd

IIRC, 127 means that “The supplied command cannot be found”, but I’m sure my binary exists, so what’s the problem?

To get into this container, we need /bin/bash, so I switched from scratch to alpine as a temporary:

1FROM alpine:3.10
2
3RUN apk add --no-cache bash
4...

then I tried to run that binary:

1❯ docker run -it --entrypoint /bin/bash <image> /app/<binary>
2/app/<binary>: /app/<binary>: cannot execute binary file

Why “cannot execute”?

Let’s see what the file type is:

1❯ docker run -it --entrypoint /bin/bash <image> -s
2bash-5.0# apk add file
3bash-5.0# file /app/<binary>
4/app/binary: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, Go BuildID=9goElUU1Hmb_TUJeOeZr/vWwqHpXL1j9jP4lLwfaC/JmUJczr0kCVHg1u9gMuT/orDzu6T6STfr9G_YODTe, stripped

What? Why “dynamically linked”?

Turned out that I forgot to specify CGO_ENABLED=0 when building, so it was dynamically linked:

1bash-5.0# ldd /app/<binary>
2	/lib64/ld-linux-x86-64.so.2 (0x7f1f8b561000)
3	libpthread.so.0 => /lib64/ld-linux-x86-64.so.2 (0x7f1f8b561000)
4	libc.so.6 => /lib64/ld-linux-x86-64.so.2 (0x7f1f8b561000)

These does not exist, so the container exited with code 127 immediately.

Tags:


docker


Related Posts:

  • Docker Compose healthcheck
  • condition form of depends_on in docker-compose version 3
  • Let’s Encrypt too many certificates already issued
  • plugins/docker failed to resolve Keycloak hostname?
  • gocloud — writing data to a bucket: 403
RUN source protected-env/bin/activate

makes no sense.

activate is a script that sets a few environment variables for the current shell; however, the current shell dies directl after sourcing that file. So, it has no effect. Especially, it has no effect on the next line!

Your error, however, stems from the fact that you’re trying to run a bash script with sh, which doesn’t work. Solution here is to put all these things (sourceing the activate file, installing things using pip) into a single shell script that starts with #!/bin/bash, so that it can be executed in one go, and then COPYing it into your container image, then RUNning that.

However, I’ve not yet encountered a reason to install numpy via pip. You should probably not do that, but install it using apt!

Same, and even more so, applies to python itself. Don’t build that from source – I don’t know where your guide is from, but seriously, that’s a terrible idea. Your ubuntu comes with Python3, most probably even preinstalled, or installable as apt install python3, done! In total, you’d just add python3-numpy to the end of your list of packages to install, and be done; no downloading python, no building it, and certainly no need to source some activate file and install numpy via pip!

When you try do dockerize ASP.NET Core application with Angular, you most probably faced with this error.

The command “npm install” exited with code 127.

So, why it happens ?

Because of publish  stage happens on based microsoft/dotnet:2.1-sdk image. So, this dockerfile contains only dotnet sdk but not npm installed this base image.

What is the solution ?

We should use other image in our dockerfile too. In order to be able build our frontend.

I seperated npm side as different build stage on dockerfile. So, firstly you should remove npm commands on publish in *.csproj file. So, i removed all red lines entirely  from my *.csproj file.

<Project Sdk="Microsoft.NET.Sdk.Web">

<PropertyGroup>
 <TargetFramework>netcoreapp2.1</TargetFramework>
 <TypeScriptCompileBlocked>true</TypeScriptCompileBlocked>
 <TypeScriptToolsVersion>Latest</TypeScriptToolsVersion>
 <IsPackable>false</IsPackable>
 <SpaRoot>ClientApp</SpaRoot>
 <DefaultItemExcludes>$(DefaultItemExcludes);$(SpaRoot)node_modules**</DefaultItemExcludes>

<!-- Set this to true if you enable server-side prerendering -->
 <BuildServerSideRenderer>false</BuildServerSideRenderer>
 <DockerDefaultTargetOS>Linux</DockerDefaultTargetOS>
 <UserSecretsId>780680aa-e49b-4ae0-b3bc-868cb1e482aa</UserSecretsId>
 </PropertyGroup>

<ItemGroup>
 <PackageReference Include="Microsoft.AspNetCore.App" />
 <PackageReference Include="Microsoft.AspNetCore.Razor.Design" Version="2.1.2" PrivateAssets="All" />
 <PackageReference Include="Microsoft.AspNetCore.SpaServices.Extensions" Version="2.1.1" />
 <PackageReference Include="Microsoft.VisualStudio.Azure.Containers.Tools.Targets" Version="1.0.2105168" />
 </ItemGroup>

<ItemGroup>
 <!-- Don't publish the SPA source files, but do show them in the project files list -->
 <Content Remove="$(SpaRoot)**" />
 <None Include="$(SpaRoot)**" Exclude="$(SpaRoot)node_modules**" />
 </ItemGroup>

<Target Name="DebugEnsureNodeEnv" BeforeTargets="Build" Condition=" '$(Configuration)' == 'Debug' And !Exists('$(SpaRoot)node_modules') ">
 <!-- Ensure Node.js is installed -->
 <Exec Command="node --version" ContinueOnError="true">
 <Output TaskParameter="ExitCode" PropertyName="ErrorCode" />
 </Exec>
 <Error Condition="'$(ErrorCode)' != '0'" Text="Node.js is required to build and run this project. To continue, please install Node.js from https://nodejs.org/, and then restart your command prompt or IDE." />
 <Message Importance="high" Text="Restoring dependencies using 'npm'. This may take several minutes..." />
 <Exec WorkingDirectory="$(SpaRoot)" Command="npm install" />
 </Target>

<Target Name="PublishRunWebpack" AfterTargets="ComputeFilesToPublish">
 <!-- As part of publishing, ensure the JS resources are freshly built in production mode -->
 <Exec WorkingDirectory="$(SpaRoot)" Command="npm install" />
 <Exec WorkingDirectory="$(SpaRoot)" Command="npm run build -- --prod" />
 <Exec WorkingDirectory="$(SpaRoot)" Command="npm run build:ssr -- --prod" Condition=" '$(BuildServerSideRenderer)' == 'true' " />

<!-- Include the newly-built files in the publish output -->
 <ItemGroup>
 <DistFiles Include="$(SpaRoot)dist**; $(SpaRoot)dist-server**" />
 <DistFiles Include="$(SpaRoot)node_modules**" Condition="'$(BuildServerSideRenderer)' == 'true'" />
 <ResolvedFileToPublish Include="@(DistFiles->'%(FullPath)')" Exclude="@(ResolvedFileToPublish)">
 <RelativePath>%(DistFiles.Identity)</RelativePath>
 <CopyToPublishDirectory>PreserveNewest</CopyToPublishDirectory>
 </ResolvedFileToPublish>
 </ItemGroup>
 </Target>

</Project>

So, try to build docker file again, it should be build without any error.

docker build -t angularapp2 .

Yes, it was successfull. But on this way we builded dockerfile only with backend but not with frontend side. We should build and publish our frontend in dockerfile. So, my Dockerfile looks like this:

FROM microsoft/dotnet:2.1-aspnetcore-runtime AS base
WORKDIR /app
EXPOSE 80
EXPOSE 443

FROM microsoft/dotnet:2.1-sdk AS build
WORKDIR /src
COPY ["angularApp2.csproj", "angularApp2/"]
RUN dotnet restore "angularApp2/angularApp2.csproj"
COPY . angularApp2/
WORKDIR "/src/angularApp2"
RUN dotnet build "angularApp2.csproj" -c Release -o /app

FROM build AS publish
RUN dotnet publish "angularApp2.csproj" -c Release -o /app

FROM base AS final
WORKDIR /app
COPY --from=publish /app .
ENTRYPOINT ["dotnet", "angularApp2.dll"]

I added frontend build stage to this file, after changes my code will look like below:

FROM microsoft/dotnet:2.1-aspnetcore-runtime AS base
WORKDIR /app
EXPOSE 80
EXPOSE 443

FROM microsoft/dotnet:2.1-sdk AS build
WORKDIR /src
COPY ["angularApp2.csproj", "angularApp2/"]
RUN dotnet restore "angularApp2/angularApp2.csproj"
COPY . angularApp2/
WORKDIR "/src/angularApp2"
RUN dotnet build "angularApp2.csproj" -c Release -o /app

FROM build AS publish
RUN dotnet publish "angularApp2.csproj" -c Release -o /app

#Angular build
FROM node as nodebuilder

# set working directory
RUN mkdir /usr/src/app
WORKDIR /usr/src/app

# add `/usr/src/app/node_modules/.bin` to $PATH
ENV PATH /usr/src/app/node_modules/.bin:$PATH


# install and cache app dependencies
COPY ClientApp/package.json /usr/src/app/package.json
RUN npm install
RUN npm install -g @angular/cli@1.7.0 --unsafe

# add app

COPY ClientApp/. /usr/src/app

RUN npm run build

#End Angular build

FROM base AS final
WORKDIR /app
COPY --from=publish /app .
RUN mkdir -p /app/ClientApp/dist
COPY --from=nodebuilder /usr/src/app/dist/. /app/ClientApp/dist/
ENTRYPOINT ["dotnet", "angularApp2.dll"]

And build you docker image again and run it.

docker build -t angularapp2 .
docker run -p 80:80 -d angularapp2

yaay it works 😊


#docker #dockerfile #python-3.7 #ubuntu-20.04

Вопрос:

Окружающая среда:

 Ubuntu 20.04.3 LTS
Docker version 20.10.8, build 3967b7d
Kernel version 5.11.0-27-generic
 

Докерфайл

 FROM python:3.7-slim-buster as base

RUN echo 'deb http://deb.debian.org/debian testing main' >> /etc/apt/sources.list 

    amp;amp; apt-get update -y 

    amp;amp; apt-get --fix-broken install -y libssl1.1 python3-dev python3-pip python3-setuptools cmake build-essential libgl1-mesa-glx ffmpeg libsm6 libxext6 gcc-10 wget libpq-dev 

    amp;amp; rm -rf /var/lib/apt/lists/*
    .
    .
    .
 

При выполнении приведенной ниже команды я получаю журналы ошибок, которые отображаются ниже.

 sudo docker build -t ProjectImage:0.0.1 .
 

Журналы ошибок

 .
.
.
debconf: delaying package configuration, since apt-utils is not installed
Fetched 275 MB in 2min 22s (1937 kB/s)
Selecting previously unselected package gcc-11-base:amd64.
(Reading database ... 6840 files and directories currently installed.)
Preparing to unpack .../gcc-11-base_11.2.0-4_amd64.deb ...
Unpacking gcc-11-base:amd64 (11.2.0-4) ...
Setting up gcc-11-base:amd64 (11.2.0-4) ...
Selecting previously unselected package libgcc-s1:amd64.
(Reading database ... 6845 files and directories currently installed.)
Preparing to unpack .../libgcc-s1_11.2.0-4_amd64.deb ...
Unpacking libgcc-s1:amd64 (11.2.0-4) ...
Replacing files in old package libgcc1:amd64 (1:8.3.0-6) ...
Setting up libgcc-s1:amd64 (11.2.0-4) ...
(Reading database ... 6847 files and directories currently installed.)
Preparing to unpack .../libc6_2.31-17_amd64.deb ...
debconf: unable to initialize frontend: Dialog
debconf: (TERM is not set, so the dialog frontend is not usable.)
debconf: falling back to frontend: Readline
debconf: unable to initialize frontend: Readline
debconf: (Can't locate Term/ReadLine.pm in @INC (you may need to install the Term::ReadLine module) (@INC contains: /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.28.1 /usr/local/share/perl/5.28.1 /usr/lib/x86_64-linux-gnu/perl5/5.28 /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl/5.28 /usr/share/perl/5.28 /usr/local/lib/site_perl /usr/lib/x86_64-linux-gnu/perl-base) at /usr/share/perl5/Debconf/FrontEnd/Readline.pm line 7.)
debconf: falling back to frontend: Teletype
Checking for services that may need to be restarted...
Checking init scripts...
Unpacking libc6:amd64 (2.31-17) over (2.28-10) ...
Setting up libc6:amd64 (2.31-17) ...
/usr/bin/perl: error while loading shared libraries: libcrypt.so.1: cannot open shared object file: No such file or directory
dpkg: error processing package libc6:amd64 (--configure):
 installed libc6:amd64 package post-installation script subprocess returned error exit status 127
Errors were encountered while processing:
 libc6:amd64
E: Sub-process /usr/bin/dpkg returned an error code (1)
 

Сборка завершится неудачно, и ошибка будет зарегистрирована, как указано выше.

Я пытался обновить свою операционную систему, удалить неиспользуемые пакеты, использовать новую операционную систему для создания образа docker, но она всегда возвращала эту ошибку. Есть ли что-то, что я упускаю из виду? Например, некоторые требуемые зависимости или некоторые несовместимые версии пакетов? Спасибо

Комментарии:

1. Вы пытаетесь выполнить крупномасштабное обновление ОС внутри своего файла Dockerfile; libc6 пакет является системным компонентом очень низкого уровня. Можете ли вы запустить файл Dockerfile FROM на более новой базе Python или Debian, у которой уже есть нужная вам версия?

2. @DavidMaze я пытался использовать FROM python:3.9.7-slim-buster as base , но все равно попал в эту ошибку. Я не слишком уверен, что пакет libc6, который мне нужен, находится в этой версии, хотя это один из новых пакетов на сайте python docker hub . Я попробовал «С 3.10.0rc2-slim-buster в качестве базы», но я считаю, что в моем синтаксисе есть ошибка, у меня нет репозитория

3. @DavidMaze Я обнаружил, что был неосторожен и пропустил python: в своей сборке версии 3.10. После использования новейшей версии FROM python:3.10.0rc2-slim-buster as base я смог решить эту проблему. Спасибо

Ответ №1:

Как прокомментировал @DavidMaze

В исходном файле dockerfile использовалась более старая версия python, которая содержит старую версию libc6 .

И поскольку файл dockerfile используется для крупномасштабного обновления операционной системы, это может вызвать проблемы с устаревшим системным компонентом очень низкого уровня.

Измените заголовок файла dockerfile с FROM python:3.7-slim-buster as base на FROM python:3.10.0rc2-slim-buster as base который будет использоваться версия python с более новой версией libc6

Понравилась статья? Поделить с друзьями:
  • Do you speak english in the class где ошибка
  • Do you know where is the bank где ошибка
  • Do you have some room service ошибка
  • Do smart summary error log scan on startup перевод
  • Do seagulls crying above the black sea ошибка