# Docker Container Does Not Start **URL:** \ **Category:** Maker\ **Created:** [February 28, 2021, 7:14pm UTC](https://forum.inductiveautomation.com/t/docker-container-does-not-start/43915 "2021-02-28T19:14:17Z")\ **Posts on this page:** 13\ **Page:** 1
**Author:** ![deon.korb](https://avatars.discourse-cdn.com/v4/letter/d/8c91f0/32.png) [@deon.korb](https://forum.inductiveautomation.com/u/deon.korb)\ **Post date:** [February 28, 2021, 7:14pm UTC](https://forum.inductiveautomation.com/t/docker-container-does-not-start/43915/1 "2021-02-28T19:14:17Z")
Hi, I’ve been using @kcollins Docker containers for a while, but after attempting to upgrade to 8.1.2, I cannot get it to start. The container remains in restarting state and I see this in the logs: ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/e/1/e1243d8fb306f8cb26b90d073bf21480572219ef.png) Way down in the nanosleep lines this appears: ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/9/4/9439d2d0712e67d0047b6f488de1e5c916876fe6.png) I’ve even tried to pull and run 8.1.1, but same happens. This is my run command: ```auto docker run -p 8088:8088 --name RPiIgnitionMaker --restart=always \ -e TZ=Africa/Johannesburg \ -e GATEWAY_ADMIN_USERNAME= \ -e GATEWAY_ADMIN_PASSWORD= \ -v my-ignition-data:/var/lib/ignition/data \ -e IGNITION_EDITION=maker \ -e IGNITION_LICENSE_KEY=\ -e IGNITION_ACTIVATION_TOKEN= \ -e GATEWAY_MODULES_ENABLED=opc-ua,perspective,sfc,tag-historian -d kcollins/ignition:latest ``` Running on Pi 2. Please help, even just to get 8.1.1 running again. Regards, Deon ---
**Author:** ![kcollins](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kcollins/32/19646_2.png) [@kcollins](https://forum.inductiveautomation.com/u/kcollins)\ **Post date:** [March 1, 2021, 3:19pm UTC](https://forum.inductiveautomation.com/t/docker-container-does-not-start/43915/2 "2021-03-01T15:19:43Z")
This has to do with some system-related issues on Raspberry Pi 32-bit… For the moment, add the extended privileges flag, `--privileged` to your run command… I’ll follow-up with more specific guidance. 🙂 ---
**Author:** ![deon.korb](https://avatars.discourse-cdn.com/v4/letter/d/8c91f0/32.png) [@deon.korb](https://forum.inductiveautomation.com/u/deon.korb)\ **Post date:** [March 1, 2021, 3:31pm UTC](https://forum.inductiveautomation.com/t/docker-container-does-not-start/43915/3 "2021-03-01T15:31:52Z")
Running again! Thanks! I’m keen to know more. Even if it means it’s time to upgrade to a Pi 4 ---
**Author:** ![kcollins](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kcollins/32/19646_2.png) [@kcollins](https://forum.inductiveautomation.com/u/kcollins)\ **Post date:** [March 1, 2021, 3:34pm UTC](https://forum.inductiveautomation.com/t/docker-container-does-not-start/43915/4 "2021-03-01T15:34:06Z")
The issue with “No monotonic clock was available - timed services may be adversely affected if the time-of-day clock changes” or “nanosleep(100ms) failed. Operation not permitted” (wanted to place those explicit messages in for the search later 🙂 ) seems to only occur on recent Raspbian 32-bit installations running Docker. It seems that [this issue report](https://github.com/AdoptOpenJDK/openjdk-docker/issues/469) discusses the need for `libseccomp2` library to be updated to address this issue. This solved the problem for me on a Raspbian 32-bit install: ```auto # Install a few prerequisite packages to be able to do the build sudo apt install build-essential git gperf # Download the libseccomp2 release package and unpack wget https://github.com/seccomp/libseccomp/releases/download/v2.5.1/libseccomp-2.5.1.tar.gz tar zvxf libseccomp-2.5.1.tar.gz cd libseccomp-2.5.1 # Build and install ./configure && make sudo make install # Preserve the original libraries from the .deb package from the base install mkdir ~/old-libs sudo mv /usr/lib/arm-linux-gnuabihf/libseccomp.so.2* ~/old-libs/ # Remove the library cache and rebuild sudo rm /etc/ld.so.cache sudo ldconfig ``` Once I updated `libseccomp2`, I was able to start the container without privileged mode. One additional note/disclaimer on the steps above–these updates are being done outside the scope of the package manager and may cause things in the future to break. I couldn’t find the equivalent of a debian backports repo for Raspberry Pi OS; there may be a “more official” way to get that library up-to-date. Hope this helps! Kevin C. ---
**Author:** ![kcollins](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kcollins/32/19646_2.png) [@kcollins](https://forum.inductiveautomation.com/u/kcollins)\ **Post date:** [March 1, 2021, 3:35pm UTC](https://forum.inductiveautomation.com/t/docker-container-does-not-start/43915/5 "2021-03-01T15:35:12Z")
> [@deon.korb](#): > > I’m keen to know more. Even if it means it’s time to upgrade to a Pi 4 FWIW, I did all my reproduction steps for this particular issue on a RPi 4.. So you'd have fought it there, too 🙂 . ---
**Author:** ![deon.korb](https://avatars.discourse-cdn.com/v4/letter/d/8c91f0/32.png) [@deon.korb](https://forum.inductiveautomation.com/u/deon.korb)\ **Post date:** [March 1, 2021, 3:43pm UTC](https://forum.inductiveautomation.com/t/docker-container-does-not-start/43915/6 "2021-03-01T15:43:45Z")
Any particular danger in just leaving it priviledged? ---
**Author:** ![kcollins](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kcollins/32/19646_2.png) [@kcollins](https://forum.inductiveautomation.com/u/kcollins)\ **Post date:** [March 2, 2021, 2:48pm UTC](https://forum.inductiveautomation.com/t/docker-container-does-not-start/43915/7 "2021-03-02T14:48:55Z")
I suppose it depends on your use case… Sometimes it can be used for devices like Raspberry Pi in order for the container to interface with host-level devices (like GPIO, for example); these would normally not be visible/accessible from a container. ---
**Author:** ![zvannest](https://avatars.discourse-cdn.com/v4/letter/z/91b2a8/32.png) [@zvannest](https://forum.inductiveautomation.com/u/zvannest)\ **Post date:** [March 4, 2021, 11:45pm UTC](https://forum.inductiveautomation.com/t/docker-container-does-not-start/43915/8 "2021-03-04T23:45:29Z")
I am having some similar issues when trying to download Ignition on my Pi 4. I used ```auto sudo docker run -p 8088:8088 --name my-ignition -e GATEWAY_ADMIN_PASSWORD=password -e IGNITION_EDITION=full -d kcollins/ignition:nightly ``` which downloaded with no issues. However when I start the container it starts, but after a second it stops with an exit code 1. Is there any help you can offer. ---
**Author:** ![Kevin.Collins](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.collins/32/13497_2.png) [@Kevin.Collins](https://forum.inductiveautomation.com/u/Kevin.Collins)\ **Post date:** [March 5, 2021, 4:30am UTC](https://forum.inductiveautomation.com/t/docker-container-does-not-start/43915/9 "2021-03-05T04:30:01Z")
What output do you have from `sudo docker logs my-ignition`? Also, are you running on 32-bit Raspbian OS? (output from `uname -a` would help) ---
**Author:** ![zvannest](https://avatars.discourse-cdn.com/v4/letter/z/91b2a8/32.png) [@zvannest](https://forum.inductiveautomation.com/u/zvannest)\ **Post date:** [March 5, 2021, 3:27pm UTC](https://forum.inductiveautomation.com/t/docker-container-does-not-start/43915/10 "2021-03-05T15:27:50Z")
Here is the output from sudo docker logs ```auto wrapper | nanosleep(100ms) failed. Operation not permitted sleep: cannot read realtime clockwrapper : Operation not permitted | nanosleep(100ms) failed. Operation not permitted wrapper | nanosleep(100ms) failed. Operation not permitted wrapper | nanosleep(100ms) failed. Operation not permitted wrapper | nanosleep(100ms) failed. Operation not permitted wrapper | nanosleep(100ms) failed. Operation not permitted wrapper | nanosleep(100ms) failed. Operation not permitted wrapper | nanosleep(100ms) failed. Operation not permitted wrapper | Startup failed: Timed out waiting for a signal from the JVM. wrapper | nanosleep(100ms) failed. Operation not permitted wrapper | nanosleep(100ms) failed. Operation not permitted wrapper | nanosleep(100ms) failed. Operation not permitted wrapper | nanosleep(100ms) failed. Operation not permitted wrapper | nanosleep(100ms) failed. Operation not permitted wrapper | nanosleep(100ms) failed. Operation not permitted wrapper | nanosleep(100ms) failed. Operation not permitted wrapper | nanosleep(100ms) failed. Operation not permitted wrapper | nanosleep(100ms) failed. Operation not permitted wrapper | nanosleep(100ms) failed. Operation not permitted wrapper | nanosleep(100ms) failed. Operation not permitted wrapper | nanosleep(100ms) failed. Operation not permitted wrapper | nanosleep(100ms) failed. Operation not permitted wrapper | nanosleep(100ms) failed. Operation not permitted wrapper | nanosleep(100ms) failed. Operation not permitted wrapper | nanosleep(100ms) failed. Operation not permitted wrapper | nanosleep(100ms) failed. Operation not permitted wrapper | nanosleep(100ms) failed. Operation not permitted wrapper | nanosleep(100ms) failed. Operation not permitted wrapper | nanosleep(100ms) failed. Operation not permitted wrapper | JVM did not exit on request, termination requested. wrapper | nanosleep(100ms) failed. Operation not permitted wrapper | nanosleep(100ms) failed. Operation not permitted wrapper | nanosleep(100ms) failed. Operation not permitted wrapper | nanosleep(100ms) failed. Operation not permitted wrapper | nanosleep(100ms) failed. Operation not permitted wrapper | nanosleep(100ms) failed. Operation not permitted wrapper | nanosleep(100ms) failed. Operation not permitted wrapper | nanosleep(100ms) failed. Operation not permitted wrapper | nanosleep(100ms) failed. Operation not permitted wrapper | nanosleep(100ms) failed. Operation not permitted wrapper | nanosleep(100ms) failed. Operation not permitted wrapper | nanosleep(100ms) failed. Operation not permitted wrapper | nanosleep(100ms) failed. Operation not permitted wrapper | nanosleep(100ms) failed. Operation not permitted wrapper | nanosleep(100ms) failed. Operation not permitted wrapper | nanosleep(100ms) failed. Operation not permitted wrapper | nanosleep(100ms) failed. Operation not permitted wrapper | nanosleep(100ms) failed. Operation not permitted wrapper | nanosleep(100ms) failed. Operation not permitted wrapper | nanosleep(100ms) failed. Operation not permitted wrapper | nanosleep(100ms) failed. Operation not permitted wrapper | nanosleep(100ms) failed. Operation not permitted wrapper | There were 5 failed launches in a row, each lasting less than 300 seconds. Giving up. wrapper | There may be a configuration problem: please check the logs. wrapper | nanosleep(100ms) failed. Operation not permitted wrapper | nanosleep(100ms) failed. Operation not permitted wrapper | nanosleep(100ms) failed. Operation not permitted wrapper | nanosleep(100ms) failed. Operation not permitted wrapper | nanosleep(100ms) failed. Operation not permitted wrapper | nanosleep(100ms) failed. Operation not permitted wrapper | nanosleep(100ms) failed. Operation not permitted wrapper | nanosleep(100ms) failed. Operation not permitted wrapper | nanosleep(100ms) failed. Operation not permitted wrapper | nanosleep(100ms) failed. Operation not permitted wrapper | nanosleep(100ms) failed. Operation not permitted wrapper | --> Wrapper Started as Console wrapper | Java Service Wrapper Standard Edition 32-bit 3.5.42 wrapper | Copyright (C) 1999-2020 Tanuki Software, Ltd. All Rights Reserved. wrapper | http://wrapper.tanukisoftware.com wrapper | Licensed to Inductive Automation for Inductive Automation wrapper | wrapper | Wrapper Process has not received any CPU time for 36 seconds. Extending timeouts. wrapper | Launching a JVM... jvm 1 | OpenJDK Client VM warning: No monotonic clock was available - timed services may be adversely affected if the time-of-day clock changes wrapper | JVM received a signal SIGKILL (9). wrapper | JVM process is gone. wrapper | JVM exited after being requested to terminate. wrapper | Reloading Wrapper configuration... wrapper | Please set wrapper.java.version.output to TRUE, relaunch the Wrapper to print out the Java version output, and send the log file to support@tanukisoftware.com. wrapper | JVM process is gone. wrapper | Wrapper Process has not received any CPU time for 23 seconds. Extending timeouts. wrapper | Launching a JVM... jvm 2 | OpenJDK Client VM warning: No monotonic clock was available - timed services may be adversely affected if the time-of-day clock changes wrapper | JVM received a signal SIGKILL (9). wrapper | JVM process is gone. wrapper | JVM exited after being requested to terminate. wrapper | Reloading Wrapper configuration... wrapper | Please set wrapper.java.version.output to TRUE, relaunch the Wrapper to print out the Java version output, and send the log file to support@tanukisoftware.com. wrapper | JVM process is gone. wrapper | Wrapper Process has not received any CPU time for 39 seconds. Extending timeouts. wrapper | Launching a JVM... jvm 3 | OpenJDK Client VM warning: No monotonic clock was available - timed services may be adversely affected if the time-of-day clock changes wrapper | JVM received a signal SIGKILL (9). wrapper | JVM process is gone. wrapper | JVM exited after being requested to terminate. wrapper | Reloading Wrapper configuration... wrapper | Please set wrapper.java.version.output to TRUE, relaunch the Wrapper to print out the Java version output, and send the log file to support@tanukisoftware.com. wrapper | JVM process is gone. wrapper | Wrapper Process has not received any CPU time for 39 seconds. Extending timeouts. wrapper | Launching a JVM... jvm 4 | OpenJDK Client VM warning: No monotonic clock was available - timed services may be adversely affected if the time-of-day clock changes wrapper | JVM received a signal SIGKILL (9). wrapper | JVM process is gone. wrapper | JVM exited after being requested to terminate. wrapper | Reloading Wrapper configuration... wrapper | JVM process is gone. wrapper | Wrapper Process has not received any CPU time for 22 seconds. Extending timeouts. wrapper | Launching a JVM... jvm 5 | OpenJDK Client VM warning: No monotonic clock was available - timed services may be adversely affected if the time-of-day clock changes wrapper | JVM received a signal SIGKILL (9). wrapper | JVM process is gone. wrapper | JVM exited after being requested to terminate. wrapper | <-- Wrapper Stopped ``` And here is the Output from uname -a ```auto Linux raspberrypi 5.10.17-v7l+ #1403 SMP Mon Feb 22 11:33:35 GMT 2021 armv7l GNU/Linux ``` ---
**Author:** ![Kevin.Collins](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.collins/32/13497_2.png) [@Kevin.Collins](https://forum.inductiveautomation.com/u/Kevin.Collins)\ **Post date:** [March 5, 2021, 3:46pm UTC](https://forum.inductiveautomation.com/t/docker-container-does-not-start/43915/11 "2021-03-05T15:46:48Z")
Yup, looks just like the issue above… Use some of the options mentioned above to get you going… Easiest is just adding the `--privileged` flag to your `docker run` statement. This particular issue isn’t anything wrong with the container itself, but rather the system-level libraries that the container runtime uses. ---
**Author:** ![zvannest](https://avatars.discourse-cdn.com/v4/letter/z/91b2a8/32.png) [@zvannest](https://forum.inductiveautomation.com/u/zvannest)\ **Post date:** [March 5, 2021, 4:41pm UTC](https://forum.inductiveautomation.com/t/docker-container-does-not-start/43915/12 "2021-03-05T16:41:27Z")
That worked thank you. I guess I was just putting `--privilaged` in the wrong spot. ---
**Author:** ![ken.maze](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/ken.maze/32/85876_2.png) [@ken.maze](https://forum.inductiveautomation.com/u/ken.maze)\ **Post date:** [May 27, 2021, 2:41am UTC](https://forum.inductiveautomation.com/t/docker-container-does-not-start/43915/13 "2021-05-27T02:41:45Z")
–privileged worked for me. Thanks!