Do not remove graph when container exits

[steinybot]

Thanks for the app, it is really handy.

I was wondering if there is a way to prevent the graph from being removed when the container exits? I am using it to monitor a container which is getting killed by the OOM killer and it would be nice to keep the graph around after it has been killed.

[vasilmkd]

That's an interesting use case. Do you mind providing a bit more detail?

[steinybot]

Sure, what part should I elaborate on?

For my particular case I was wanting to see what the memory usage was at the point that the process was killed and the container exited. What I ended up doing was taking a screen recording and then extracting the frame from the video at the point the container was killed. It would have been better if I didn't have to resort to taking a video. Even better would have been if I could have then gone back and put the cursor over the peak in the graph to see what the value was at that point.

[vasilmkd]

That sounds like an elaborate workaround.

Sure, I can make containers stay after being removed, and I will mark them as stopped/removed. Regarding the interactive graph, I think that may be a limitation of the Javascript library I chose for the task, but that too is changeable.

Thank you for the great suggestion. I will incorporate it into the project.

[vasilmkd]

Addressed in #45.

@steinybot I have made changes to the whole application UI. All containers are shown, regardless of whether they are running or stopped (removed containers are obviously not shown and are removed from the UI). Each container row is now collapsible, so container data can be shown on a per container basis.

Do you mind checking out the new implementation and updating this issue?
Thank you.

[steinybot]

Looks great so far! I like the blue for the graph.

I don't know if it is related to these changes but I just encountered an exception:

[blaze-selector-3] INFO org.http4s.blaze.channel.nio1.NIO1SocketServerGroup - Accepted connection from /172.17.0.1:49244
[ioapp-compute-1] ERROR org.http4s.blazecore.websocket.Http4sWSStage - Error closing Web Socket
java.lang.StringIndexOutOfBoundsException: begin 0, end 12, length 0
	at java.lang.String.checkBoundsBeginEnd(String.java:3319)
	at java.lang.String.substring(String.java:1874)
	at server.Stats$.$anonfun$parseParts$1(Stats.scala:39)
	at cats.ApplicativeError.catchNonFatal(ApplicativeError.scala:203)
	at cats.ApplicativeError.catchNonFatal$(ApplicativeError.scala:202)
	at cats.effect.IOLowPriorityInstances$IOEffect.catchNonFatal(IO.scala:852)
	at server.Stats$.parseParts(Stats.scala:35)
	at server.Stats$.$anonfun$parseCSV$1(Stats.scala:23)
	at cats.effect.internals.IORunLoop$.cats$effect$internals$IORunLoop$$loop(IORunLoop.scala:145)
	at cats.effect.internals.IORunLoop$RestartCallback.signal(IORunLoop.scala:366)
	at cats.effect.internals.IORunLoop$RestartCallback.apply(IORunLoop.scala:387)
	at cats.effect.internals.IORunLoop$RestartCallback.apply(IORunLoop.scala:330)
	at cats.effect.internals.IOShift$Tick.run(IOShift.scala:36)
	at cats.effect.internals.PoolUtils$$anon$2$$anon$3.run(PoolUtils.scala:52)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
	at java.lang.Thread.run(Thread.java:834)
	at com.oracle.svm.core.thread.JavaThreads.threadStartRoutine(JavaThreads.java:517)
	at com.oracle.svm.core.posix.thread.PosixJavaThreads.pthreadStartRoutine(PosixJavaThreads.java:193)

I'll repeat what I just did and see if it happens again.

[steinybot]

Ok so it does seem to be reproducible. Here is what I did:

1. Ran the monitor.
2. Started another container which was running a Java process which was suspended waiting for the debugger to attach.
3. Set a breakpoint to occur when an exception is thrown.
4. Attached the debugger.
5. Waited for the stats of that new container to be shown in the monitor.
6. Allowed the process to continue and throw the exception which causes the process and the container to exit with a non-zero exit code.

[vasilmkd]

Somehow it seems that the id of the container is not being reported properly, and this is a parsing exception. Does the monitor work after this or does it stop completely?

[vasilmkd]

Opened a new issue. Closing the current one because the original issue has been resolved.

[steinybot]

@vasilmkd So actually I think this one should be reopened.

The container is still being removed when it exits.

[vasilmkd]

Actually I will keep this one closed. I will comment on the other issue.

[steinybot]

The container is still being removed when it exits.

This was because I was running the container with the --rm flag. I realise now your comment above stated that removed containers would not be shown. That doesn't seem strictly necessary but I guess it is reasonable behaviour. If I want to keep the graph I will just have to keep the container around it seems.

[vasilmkd]

I didn't really choose this behavior. As soon as you remove a container, Docker no longer shows any information about it, when running the set of commands that I'm using for this application. With that being said, the server part of this application is a standard HTTP server which is stateless by default (and I'd like to keep it that way), so any state is currently delegated to the client in Javascript. Maybe we can keep around the removed containers for the duration of the session, but they will be gone after a refresh of the page, and they will not receive any updates, since there aren't any.

If you really like, I could look into implementing this behavior (not removing removed containers from the UI) but I'd really like the application to show the actual state of Docker containers.

Let me know your thoughts.

[steinybot]

Maybe we can keep around the removed containers for the duration of the session, but they will be gone after a refresh of the page, and they will not receive any updates, since there aren't any.

That was my naive understanding of how it was going to work. That is already true for how it works with a running/stopped container, if you refresh you loose the historical data, so I don't think it would be surprising if a removed container disappeared. If it is much work I don't think it is necessary to change the current behaviour and you can close this again.

I agree that showing the state of the container is now more important. There are the states from docker ps which are created, restarting, running, removing, paused, exited, or dead. If you decide to keep the removed containers then we would need one for removed too.