I've just tried to deploy a Tomcat alpine container and I may have broken your workers

Product support
1

Getting confident after playing with the “getting started” example, I’ve just tried a really simple test using this Dockerfile, but replacing :
“FROM openjdk:8-jre-alpine”
with the more resin-compatible :
“FROM resin/%%RESIN_MACHINE_NAME%%-alpine-openjdk:8-jre”

As you can see in the deploy.log file, it went good til the end, but now it has been looping on “[Info] Still working…” for hours (well, dozen of minutes, but far far longer than the nodejs example).

Would you have more logs your side to tell me what is happening ? I really don’t expect the final image to be big, it may be even smaller than the nodejs example image.

Dockerfile.template (3.5 KB)

deploy.log (106.9 KB)

UPDATE : I’ve also tried “git push resin master:master-arm” after reading this thread but it gives the same result.

2

Hey Tristan,

Builder maintainer here :slight_smile: I’ve taken a look at the issues you’ve been having, and it appears the catalina.sh script runs indefinitely. Nothing has frozen or crashed on the builder side, so I believe the script either doesn’t play nice inside a Docker container, or it takes a serious amount of time.

Have you ran this script locally by any chance?

I’ll continue to do some testing, and update you if I come up with a solution.

Also the arm builders are temporarily deprecated, but watch this space :smiley:

Cameron

1 Like
3

Hi Cameron,

yes, for sure it runs indefinitely since it’s the startup script for Tomcat. Maybe npm start is starting nodejs server in background but it’s not the case for catalina.sh (and it’s totally compatible with Docker on regular environments).

What I’m trying here is the official image for Tomcat, not a Dockerfile I’d have customized in a wrong way (the only customization is the FROM).

UPDATE : I can try to replace catalina.sh “run” with catalina.sh “start” though, if it’s an absolute need that the docker CMD runs in the background.

UPDATE 2 : I’ve just pushed a version with “start” instead of “run”, but I’ve been receiving “still working” for minutes now, when it should take a few seconds to start (less than 2 seconds on a PC).

4

Ah sorry, I should have been more specific. The command which is failing to finish in a normal amount of time is catalina.sh configtest, and as it’s in a RUN step the build does not finish.

11

Oh ok, thanks for your answer, I should have read the log more carefully too.

The thing is this “official” Dockerfile is quite ambitious since it’s trying to compile the native library from C language source code, which is an optionnal thing.

I’ll get a less ambitious Dockerfile and try again. Can you confirm the last Dockerfile CMD doesn’t need to be in the background and you run it with “-d” ? (I haven’t found the doc which explains how u run containers and options)

12

The CMD step of a Dockerfile specifies with command will be ran on container start, which in the context of resin is when your device(s) start the application. You generally want this to be blocking and also run indefinitely, as the container will be restarted when it dies (i.e. the CMD step returns execution).

If you wanted to run multiple commands in the CMD step for example, the pattern which we use and generally recommend here at resin is to have a start.sh script, which can run several commands, some blocking, some background. Then your Dockerfile would end:

RUN chmod +x start.sh
CMD start.sh

Let me know if you want further details on anything, or I’ve not made myself clear :slight_smile:

Happy hacking!
Cameron

13

Ok thanks, so now I’ve simplified my Tomcat Dockerfile, and I can reach the Unicorn in a few seconds, I can even see the full expected starting log :

05.05.17 11:17:35 (+0200) Downloaded application 'registry2.resin.io/testapp/f339ed6d6cfaf6d28670d8702256d8b9b72de5d7'
05.05.17 11:17:36 (+0200) Killing application 'registry2.resin.io/testapp/95bdffab5724a4cec26a047164e03a4ce41d0a7b'
05.05.17 11:17:41 (+0200) Killed application 'registry2.resin.io/testapp/95bdffab5724a4cec26a047164e03a4ce41d0a7b'
05.05.17 11:17:42 (+0200) Installing application 'registry2.resin.io/testapp/f339ed6d6cfaf6d28670d8702256d8b9b72de5d7'
05.05.17 11:17:44 (+0200) Installed application 'registry2.resin.io/testapp/f339ed6d6cfaf6d28670d8702256d8b9b72de5d7'
05.05.17 11:17:44 (+0200) Starting application 'registry2.resin.io/testapp/f339ed6d6cfaf6d28670d8702256d8b9b72de5d7'
05.05.17 11:17:54 (+0200) Started application 'registry2.resin.io/testapp/f339ed6d6cfaf6d28670d8702256d8b9b72de5d7'
05.05.17 11:20:36 (+0200) 05-May-2017 09:20:36.799 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Djava.io.tmpdir=/opt/tomcat/temp
05.05.17 11:20:36 (+0200) 05-May-2017 09:20:36.859 INFO [main] org.apache.catalina.core.AprLifecycleListener.lifecycleEvent The APR based Apache Tomcat Native library which allows optimal performance in production environments was not found on the java.library.path: /usr/lib/jvm/java-1.8-openjdk/jre/lib/arm/server:/usr/lib/jvm/java-1.8-openjdk/jre/lib/arm:/usr/lib/jvm/java-1.8-openjdk/jre/../lib/arm:/usr/java/packages/lib/arm:/lib:/usr/lib
05.05.17 11:21:00 (+0200) 05-May-2017 09:20:59.886 INFO [main] org.apache.coyote.AbstractProtocol.init Initializing ProtocolHandler ["http-nio-8080"]
05.05.17 11:21:08 (+0200) 05-May-2017 09:21:08.860 INFO [main] org.apache.tomcat.util.net.NioSelectorPool.getSharedSelector Using a shared selector for servlet write/read
05.05.17 11:21:09 (+0200) 05-May-2017 09:21:09.526 INFO [main] org.apache.coyote.AbstractProtocol.init Initializing ProtocolHandler ["ajp-nio-8009"]
05.05.17 11:21:11 (+0200) 05-May-2017 09:21:11.510 INFO [main] org.apache.tomcat.util.net.NioSelectorPool.getSharedSelector Using a shared selector for servlet write/read
05.05.17 11:21:11 (+0200) 05-May-2017 09:21:11.665 INFO [main] org.apache.catalina.startup.Catalina.load Initialization processed in 165367 ms
05.05.17 11:21:16 (+0200) 05-May-2017 09:21:16.915 INFO [main] org.apache.catalina.core.StandardService.startInternal Starting service Catalina
05.05.17 11:21:17 (+0200) 05-May-2017 09:21:17.006 INFO [main] org.apache.catalina.core.StandardEngine.startInternal Starting Servlet Engine: Apache Tomcat/8.5.14
05.05.17 11:21:19 (+0200) 05-May-2017 09:21:19.235 INFO [main] org.apache.coyote.AbstractProtocol.start Starting ProtocolHandler ["http-nio-8080"]
05.05.17 11:21:21 (+0200) 05-May-2017 09:21:21.369 INFO [main] org.apache.coyote.AbstractProtocol.start Starting ProtocolHandler ["ajp-nio-8009"]
05.05.17 11:21:21 (+0200) 05-May-2017 09:21:21.519 INFO [main] org.apache.catalina.startup.Catalina.start Server startup in 9798 ms

And when I exec a shell in my running container, can see the expected “HTTP 404” response on querying “http://localhost:8080” :

/opt/apache-tomcat-8.5.14 # wget localhost:8080
Connecting to localhost:8080 (127.0.0.1:8080)
wget: server returned error: HTTP/1.1 404

It also works from the host :

root@30467b3:~# wget localhost:8080
Connecting to localhost:8080 (127.0.0.1:8080)
wget: server returned error: HTTP/1.1 404

and it works from my windows PC on local address :

C:\Users\Tristan>"C:\Program Files (x86)\GnuWin32\bin\wget" 192.168.1.14:8080
SYSTEM_WGETRC = c:/progra~1/wget/etc/wgetrc
syswgetrc = C:\Program Files (x86)\GnuWin32/etc/wgetrc
--2017-05-05 11:47:47--  http://192.168.1.14:8080/
Connexion vers 192.168.1.14:8080...connecté.
requête HTTP transmise, en attente de la réponse...404
2017-05-05 11:47:47 ERREUR 404: (pas de description).

BUT when I try the public device URL on port 8080, it doesn’t work, it says “ERR_CONNECTION_CLOSED” and I don’t get the expected HTTP 404. Your doc says :

“Resin.io devices expose all ports by default, meaning you can run applications which listen on any port without issue.”

So did I miss a step to declare this 8080 port, or should I fill an issue report somewhere ?

P.S. about the autorestart, according to Docker doc it’s supposed use an incremental back-off algorithm, but it looks like it’s occuring every 10 s for ever, are you by-passing docker restart mechanisms ?

14

I believe that the device opens all ports, which is what you’re seeing when you connect via the local network, but that only port 80 goes through the VPN, which is what you’re seeing via the WebURL. I’m pinging other’s more in the know to confirm this.

16

Any news about this ?

17

Hi @Tristan107, only port 80 is exposed through the Public Device URL (see the relevant docs), that is a technical limitation of the forwarding, but we’re checking whether this can be expanded (but that’s the current status)

When

That statement does not mention the Public Device URLs, the exposed ports are on the device itself, i.e. exposed on the network the device is accessible on (usually the LAN). Meaning: if you open a port in your application, any port, resinOS does not have any restriction on those ports.

Regarding the autorestart, “docker cloud” is not really the relevant thing, the correct respective docker setting is the docker run --restart documentation and for Docker 1.10.3 (see it here). The restart in our case is done by the resin-supervisor, and controlled by the RESIN_APP_RESTART_POLICY device configuration variable (and RESIN_APP_RESTART_RETRIES):

RESIN_APP_RESTART_POLICY can take one of the valid values defined by docker run --restart, that are: no, always, on-failure, unless-stopped. If the selection is on-failure, then it will try the restart as many times as RESIN_APP_RESTART_RETRIES defines it. The restart times are exactly the same as any other docker instance would do with the same settings.

Unfortunately this is not well covered in our docs (we will be fixing that), in the meantime this should be most of it.

18

Thanks for your answers. About the port, it may be only a test use case we encoutered and not a prod use case, so not a big deal.

About Docker, you are explaining me the different restart policies while I’m talking about the restart frequency which is supposed to be increasing and not constant according to Docker doc (maybe it’s a Docker bug though).

19

@Tristan107 the supervisor only sets the policy on Docker, and then it’s Docker that applies it - so if it’s not working properly it might be a Docker bug. But then again, the docs say that (at least in 1.10), if the app runs for more than 10s then the back-off is reset. Maybe this is what’s happening here? Or does the app exit immediately?

2 Likes
20

Yes, you are totally right, the bug must be about docker definition of “a container has successfully restarted”, when in facts the startup fails past 10 sec.

So I guess all subjects are closed in this thread.